I would like to try this throwing an error from the AppServer to be caught by the client, but I'm not quite sure about the implementation. Help talks about using a SERIALIZABLE class. Can you point me to a sample code?
Thanks,
Do you know of any caveat or anything that I should watch out for?
Be careful. If you try to throw it back to the client using...:
UNDO, THROW NEW yourpackage.YourError ().
...then you need to have BLOCK-LEVEL UNDO, THROW at the top of your .p or .cls file. Otherwise the error will just get raised within its current block context. Or you can do the following from the top-level AppServer procedure:
RETURN ERROR NEW yourpackage.YourError ().
For the RETURN statement, does it behave the same way when just returning a literal string, or does it need to be a ProgressError derived class when using structured error handling?
[quote user="Laura Stern"]
Be careful. If you try to throw it back to the client using...:
UNDO, THROW NEW yourpackage.YourError ().
...then you need to have BLOCK-LEVEL UNDO, THROW at the top of your .p or .cls file. Otherwise the error will just get raised within its current block context. Or you can do the following from the top-level AppServer procedure:
RETURN ERROR NEW yourpackage.YourError ().
[/quote]
I don't know what you mean by "does it behave the same way when just returning a literal string". if you return an error object instance, it needs to be a class that implements Progress.Lang.Error and it needs to be SERIALIZABLE (which all the system classes are). That's the same as with UNDO, THROW. If you just return a literal string, you can catch it on the client as an AppObject where the ReturnValue property will be set to that string value. Or you can just handle the error the non-structured error-handling way (with DO ON STOP, or whatever), and the RETURN-VALUE function will return that string.
I don't know what you mean by "does it behave the same way when just returning a literal string". if you return an error object instance, it needs to be a class that implements Progress.Lang.Error and it needs to be SERIALIZABLE (which all the system classes are). That's the same as with UNDO, THROW. If you just return a literal string, you can catch it on the client as an AppObject where the ReturnValue property will be set to that string value. Or you can just handle the error the non-structured error-handling way (with DO ON STOP, or whatever), and the RETURN-VALUE function will return that string.
Interesting article on the throw keyword: hackernoon.com/the-throw-keyword-was-a-mistake-l9e532di
https://www.monitis.com/blog/improving-net-application-performance-part-10-exception-management/
https://mattwarren.org/2016/12/20/Why-Exceptions-should-be-Exceptional/
I had a long post here and I deleted it because this isn't the right thread. agent_008...if you want to start a new thread, I'll be happy to rant along with you :)
You answered my question. I was just wondering if both cases (object or literal) can be processed/handled similarly using structured error handling.
Ok, will do.