D
dbeavon
Guest
My understanding is that most programming languages that support structured error handling (SEH) will provide the callstack to indicate where an unhandled exception originated. For example in C#, you have the callstack frames in a member called "StackTrace". If the information is not of interest, or sensitive, then it can be hidden fairly easily. For example, by throwing a new exception without referencing the original, it will appear that the problem originated at the current location, instead of the original one. However, for most internal business applications, the exception call stack is almost always of interest for troubleshooting purposes. Is there any plan for ABL to make the necessary improvements in SEH to allow stack information to be available by default? It takes quite a lot more effort for me to find bugs in *production* environments where -errorstack is not enabled by default. For example, if a problem is difficult to reproduce or if it only happens on rare occasion, then it is hard to weigh the cost of adding the -errorstack option for long periods of time. Ideally the exception stack in ABL could be available by *default* like it is in other languages, and not have such a high performance penalty associated with it. Note that this question was asked in another post, where it was pointed out that there is a performance penalty for using "-errorstack": https://community.progress.com/community_groups/openedge_development/f/19/t/16889 I understand that there are programming workarounds that can be applied on a case-by-case basis. But it would be far better if Progress would do the work once for all of us; instead of making it every ABL developer's job to find a way to keep track of their own error stacks, or compromise performance by turning on "-errorstack" . Neither of these options are very appealing.
Continue reading...
Continue reading...