D
dbeavon
Guest
Yes, its application level inconsistent data that is discovered deep in a callstack without a good way of notifying callers about a critical problem (no S.E.H, no error output params, no "NO-ERROR" strategy on run statements, etc). Its amazing how much of our legacy ABL code assumes no errors will ever possibly occur, either now or later after any future coding changes... I'm very happy with OE/OO which takes the opposite approach and allows for any manner of error to occur at any time (the application code then having the responsibility for handling them - but only the ones it knows about). (These days with brand new code, I would use OO to throw a unique type of error class that isn't handled by anyone. That definitely gets the job done on the OO side of things. But with poorly written legacy code, however, there is no obvious way to throw a fatal error and roll back the db). We are on 11.3, planning an upgrade to 11.6. Your KB says that sending SIGHUP corresponds to an untrappable STOP, which is why I'm inclining towards that approach. I wish there was an option on the ABL STOP statement that had the same effect. FROM YOUR KB: SIGHUP: indicate to the running process that the terminal it is trying to read or write to has disconnected. The signal is sent by the operating system as a response to a read or write operation. The Progress / OpenEdge process defines a special signal handler that will treat this as an untrappable STOP condition.
Continue reading...
Continue reading...