D
dbeavon
Guest
I can't create a general purpose fix for these errors in that program at that level of the call-stack. It is mainly because the program doesn't have all the necessary contextual information it would need to take a new course of action. IE. In my situation the program can see for itself - based on some of its own logic - that the data is invalid. But it: doesn't have authority to change anything about the data it is given. it doesn't really know how much other logic may have been done previously - leading up to that point (ie. logic that had been executed based on the invalid data) most importantly, it doesn't have a mechanism to send a back an error response to a calling program, nor allow someone else to take a new course of action (eg. generate a message to the user about the error and fail in a graceful way). Given how rare it is that the error situations come up, the choke-and-die approach seems suitable. As you say, we'd also fix the root cause if/when its possible to find it (nobody will prefer a program that chokes-and-dies over a program that succeeds). But there would be too much refactoring involved to have a general-purpose solution that would either (A) pass back an output parameter all the way up the legacy ABL callstack, or (B) try to find and fix/validate all the input data everywhere, as supplied by potentially dozens of clients to this particular program. This program is like a low-level private first class in the army. It has to do what its told without sending any unwanted outputs to its callers. It doesn't have too many options. Now if this was OO code and could use Structured Error Handling, that would be a whole different story.
Continue reading...
Continue reading...