D
dbeavon
Guest
@Laura the problem is absolutely by accident. If ABL programs and classes are using the new SEH pattern, then they will have... BLOCK-LEVEL ON ERROR UNDO, THROW. ... and errors (exceptions) cause the callstack to unwind up to a matching handler (CATCH). If there are no matching handlers, then the error is normally considered "unhandled" and typically causes a crash (at least that's what happens in the runtimes of other technologies). When this occurs, developers would expect to have access to the fatal error details (error type, member fields, and stack information, and ToString output.) Exceptions frequently find themselves being unhandled for accidental reasons (as in our case). For example, at the outer-most PersistentProcedure.p which is used for app server entry, there might be a catch block that handles *every* possible error of type Progress.Lang.AppError, but even that won't necessarily catch .Net errors (which are only catch-able using interface Progress.Lang.Error) or other types of unusual ProErrors (custom ones or otherwise). Typically a developer will catch *ONLY* the errors that they feel they understand and know how to resolve on their own. For any other errors they don't understand (or future ones that may not even exist yet) then they rely on the runtime to do something "reasonable" (even if that means causing the session to crash, and providing access to the error details for diagnostic purposes). (FYI for fatal system errors a regular ABL developer would probably be unable to do any meaningful error handling . These errors would be things like network disconnections, disks filling up, out-of-memory issues and so on. Even PASOE itself is likely to behave in unpredictable ways - IE. it's own error handlers would likely run into errors of their own, depending on how unreliable the system became.) To make a long story short, in the case of ABL/PASOE the runtime doesn't give us a "reasonable" mechanism for errors that are "unhandled" by custom ABL code. I get the generic message in the agent log, and the user sees a generic message as well. None of the underlying details about the error are provided - not even the outer-most procedure name or the -errorstack of the error. These would otherwise allow a developer to troubleshoot and fix the problem so it doesn't keep coming up in the future. I can't find any way that a developer to get to the bottom of this log message ("Cannot throw or return error/stop object to remote client because object is not serializable or client does not support it"). I shouldn't have to turn on 4GLTrace for the entire application just to find the related programs, then do additional custom programming in those ABL programs to catch the error and puke out the related details.
Continue reading...
Continue reading...