S
slacroixak
Guest
Hi all, I' like to start a discussion about minimum error handling requirements for some situations that remain in unmanageable corner cases for some historical reasons. Like many of you, we would like to catch and log any kind of ABL System Exception on the fields to better serve our customers. You all know this famous error: ** " " was not found. (293) We somehow agree it cannot be handled like any catchable exception because it is likely to be caused by a missing artefact, so a corrupted application (plus changing that would break many Apps). Our applications sometimes rely on some problematic occurrences of RUN VALUE(), which are a bit hard to wrap with a SEARCH(), but my point is not to change fundamentally this ABL behaviour and I‘d rather find a way to handle it like an unhandled exception. Error 293 leads to an untrapable STOP condition that restarts your application, with the procedure of your -p startup param. This leads to many problems when your app uses Static members, because these do remain with the context of your session before it was restarted next to that STOP. As a consequence, in a restart case, you may want to exit your App quickly. Happily, it is easy to detect this situation and exit: make your launcher procedure increment a static integer variable and make sure it does equal to 1. If greater than 1 (should be 2) then log/message something then QUIT. But... like us, you may want to go one step further: be notified what particular procedure file is missing. So far, the _msg() construct still holds the last error-numbers in case of restart, and does report 293, but without any message detail so we still do not know which procedure is missing (ERROR-STATUS:GET-MESSAGE(1) does not work indeed). I am not sure, but perhaps the loss of a database connection also falls in a similar situation. Q1: are you aware of another trick to catch the name of a missing procedure file? Please note that relying on client log is not an acceptable option. Q2: KBase 28152 ( http://knowledgebase.progress.com/articles/Article/000028152 RUN STATEMENT ERROR IS NOT CAUGHT BY STRUCTURED ERROR HANDLING ) refers to Enhancement Request OE00217716 about this topic. Is it a good ER or should we log a new one covering all the aspects? Provide a way to achieve minimum error handling for the so called untrapable stop conditions, like unhandled exception in other technologies (like UnhandledExceptionEventHandler in C#) A few suggestions, from quick and dirty to smarter: a) Associate the _msg() construct to a new _msgDetail() stack that keeps track of the full error message, and not only the message number. b) Provide a new special ON UNTRAPABLE-STOP phrase to give the ability to trigger a piece of code that would eventually end up with an implicit QUIT to override the default restart. Also make sure an error 293 gets added to the ERROR-STATUS:GET-MESSAGE() stack so we can obtain the details about what has caused it (same for other similar types of errors) c) Provide a new set of low level ABL exceptions such as Progress.Lang.System.Exception or Progress.Lang.UntrapableStopCondition.Exception that could be caught in a CATCH BLOCK, bypassing the default untrapable STOP. /Sébastien L.
Continue reading...
Continue reading...