D
dbeavon
Guest
Here is an example of a place in your documentation where application developers are being frightened into trying to get along without the benefit of any stack details: https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dverr/enabling-stack-tracing-with-error-objects.html "Examining the call stack is a valuable debugging feature, but it can potentially consume resources and it is not recommended in a production environment " In contrast, I don't recall c# or java ever claiming that exception callstacks are disallowed in production. They are an integral part of any exception and provide necessary context to interpret the error message. Note that errors are common in any app and can be raised in production just as easily as in development - because of innumerable types of unpredictable data-related issues (commonly found in database applications). There are different types of errors - some that may be an indication of a software bug which should have been found during development. But many others that are handled as a matter of course (eg. the user enters data which creates a divide-by-zero scenario - and you must tell them to knock it off). For reference, here is a fairly straightforward stackoverflow about how stack traces are used to troubleshoot unexpected exceptions in Java apps. The discussion is also relevant to ABL (if you substitute "exception" terminology with "error"). https://stackoverflow.com/questions/3988788/what-is-a-stack-trace-and-how-can-i-use-it-to-debug-my-application-errors Sorry for the long post about errors, but I want to make sure I am not misunderstanding ABL errors or how they are intended to be used. Initially it seemed possible to me that OpenEdge was trying to take a slightly different approach to SEH than the other languages. But the implementation of SEH in those other languages works the way it does for very good reasons (ie. as I'm finding in my ABL lessons that are learned the hard way).
Continue reading...
Continue reading...