H
Henri Christian Koster
Guest
Hi Laura, I agree with you that we could take the approach of wrapping everything in undo-able blocks, but I don't like the fact that we have to introduce even more blocks, which themselves introduce overhead. We have tens (if not hundreds) of thousands of lines of legacy code - and not necessarily the capacity to rework it at the moment. This was written long before structured error handling existed. Back in the day, error-handling was not nice. If you left off the NO-ERROR on a statement, OpenEdge would pop a message to a screen (GUI) or write a message to a log file, and then return to the caller that there was NO error. ERROR-STATUS:ERROR would be false and you had nothing in ERROR-STATUS:GET-MESSAGE(x) either. This could lead to disastrous results if something didn't "throw" the error back (or even knew and error occurred). You had to be manually "throw" your errors as follows (Somewhat simplified): RUN doSomething NO-ERROR. IF ERROR-STATUS:ERROR THEN DO: /* Note that we would give preference to something in RETURN-VALUE */ IF RETURN-VALUE <> ? AND RETURN-VALUE <> "":U THEN RETURN ERROR RETURN-VALUE. ELSE RETURN ERROR ERROR-STATUS:GET-MESSAGE(1) + "|" + "Build up your call stack manually here". END. When you execute code, you can get back an application generated error (RETURN ERROR "SomeError") or an error raised by the ABL (mismatched parameteers, etc.). To have any idea of where the error occurred, you had to build in the call stack as part of your RETURN-VALUE, so that developers knew where to go and find the problem. This is demonstrated with the code above. The code in the error handling block was placed in an include to ensure consistency. So you now have something like: RUN doSomething NO-ERROR. {ReturnError.i} The problem with having an error thrown back with the THROW/CATCH style error-handling is that the legacy code intercepts the error, but we have no way of getting at the original stack of where the error occurred. Therefore, we cannot patch the include file to include the correct call stack. So, as code gets modernized down the line, legacy code has an issue we can't cater for. I hear that you mention that the startup parameter was introduced for performance reasons. I have heard this previously from someone at Progress. What is the impact? I cannot imagine that you would not want to leave it on, so where is the performance issue introduced? In every statement that gets executed or only when you encounter an error? Surely it should be the latter, because that is the only point you are interested in getting the call stack? And if so, that shouldn't really matter, because you only hit this when you run into an error - which should be far less than your actual number of lines of code executed.
Continue reading...
Continue reading...
