[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Changing PASOE agent logging dynamically

  • Thread starter Thread starter dbeavon
  • Start date Start date
Status
Not open for further replies.
D

dbeavon

Guest
>> You can log a bug for this. I did report this to Progress tech support. The support case essentially end with a KB article that implies things are working as designed, see knowledgebase.progress.com/.../Tracking-down-the-root-cause-of-error-14438 ... The recommended method of troubleshooting this error message is to turn on "4GLTrace" log entry type. >> If your CATCH blocks are not for Progress.Lang.Error, they should be. Not sure why they wouldn't be already. Typically a programmer should only catch errors that they know how to handle. Outside of those specific types of errors, we rely on the execution context (ie. the runtime/framework) to do something intelligent and well-defined with the remaining errors that aren't caught. Typically the unhandled errors should be printed somewhere for post-mortem analysis, and then the execution context should be stopped and abandoned (ie. in the case of PASOE, the ABL session should probably be recycled). CATCH blocks are designed to handle errors of a specific type. The error type is used as a filter to the CATCH block. It is true that, in addition to handling well-understood application errors, I could also choose to write a CATCH block for "Progress.Lang.Error", but that seems like a very last-resort. And it isn't likely that I'll add any value by handling every unforeseeable and unexpected error in my custom code. IE Anything I might do in my custom code is the exact same thing that I would otherwise have expected the runtime/framework to do for me in the first place! (But of course, PASOE is not currently helping us very much with our unexpected errors). Note that the AppError class is documented to be the "ultimate super class of all application errors". Our custom application errors are derived from it. By catching all AppError classes (and any derived classes), we are taking care of our own responsibilities. Any error types outside of this are "above our pay grade" so to speak, and we would expect the runtime/framework to pick up the ball and perform some behavior that is intelligent and well-defined.

Continue reading...
 
Status
Not open for further replies.
Back
Top