D
dbeavon
Guest
>> If you use a CATCH block - again the message is no longer written to the output device. There is a possibility that if it's a STOP condition we still write it out to the log even if it's caught. I can't remember. I'll do some testing. If it *IS* written to the log, then there is probably no easy way to suppress that message, right? If it is *NOT* written to the log by default, then a developer could optionally write it themselves, via LOG-MANAGER. The nice thing about the new LockConflict exception is that we should theoretically have all the details needed to write the message ourselves. Whereas with the "traditional" error handling model's ON STOP phrase, you wouldn't have easy access to those lock-conflict details. Our legacy ABL programs generate quite a lot of noise in the agent log. I don't think that any error which is handled (or escapes to the client) should be printed to a log by default. Or if they are printed then that should be done based on our own custom requirements (specified via error event handlers for first-chance exception & unhandled exceptions). Of course if ABL is swallowing our errors by way of the default ON ERROR mechanism, then those types of things should continue to be printed to the logs.
Continue reading...
Continue reading...