D
dbeavon
Guest
From my perspective it isn't the whole story to simply say "they are different" Especially considering that RETURN ERROR will behave - within ABL - just like UNDO, THROW AppError. ... and as you had mentioned before, there is not even a way for a CATCH block to distinguish whether the error was originally raised one way or the other. How is that not equivalent !? I think the real problem is that there are conflicting design goals for AppError. Ideally there would have been another ("ReturnValueError") that was derived from AppError and its purpose would be much more certain than the purpose for AppError. As things are today, AppError seems like the only "go-to" error for a PASOE developer who might be trying to proxy a failure message back to the openclient. And that would work fine except for the noisy agent log. So we are stuck wrapping a CATCH around all our entry level procedures, just in order to trim the noise out of the agent log. That is a lot of very repetitive and "clunky" programming work. In the end, the solution might be to have a way for an ABL developer to introduce logging for themselves (possibly via some kind of event/trigger?). IE this could be done if we need any additional logging/behavior whenever an error is "escaping" from PASOE and is bound for the openclient. We should be able to accomplish this without repeating code in every single entry-procedure. It seems unfortunate that a PASOE application developer is at the mercy of PASOE agent to capture & log any exceptional (un-handle-able) errors that might be escaping. I think it would be very useful for a developer to introduce our own customized behavior.
Continue reading...
Continue reading...