D
dbeavon
Guest
Writing custom catch blocks too early (high in the callstack) is labor-intensive. There is usually no need to do that, nor to interact with particular exception-types that had caused a failure. As far as the user is concerned, either things worked or they didn't. If not, then show the user a message that contains a reasonable string representation of the error message. Showing a error message can happen in a generic way, as long as there is an error and a related message. In many cases, the developer may not initially be *aware* of every possible type of exception that could cause failures. (Eg. your ABL code might be running in a new and unfamiliar container, like PASOE, or the code may be interacting with unfamiliar services that were written by a third-party). So initially you treat all exceptions the same and, over time, if you want to handle some of them differently you might do that (with retry logic, or customized messages, etc). Some types of exceptions (concurrency timeouts for example) happen so infrequently that we might never choose to clutter the code with any specific references to them at all - if we can avoid it. So long as the user gets a somewhat meaningful failure message and understands how to take a follow-up action, then things are fine. In summary ... our exceptions will be treated in the most generic way possible, unless there is a really, really good reason to micro-manage one of the exception-types. We don't initially start by trying to micro-manage every possible exception-type if we can avoid it.
Continue reading...
Continue reading...