Argumentative? Hardly. This is a serous discussion, and we have to be free to bring forth stuff.

I agree. But let's see if we can agree on terms. What exactly does a global error handler DO? Handle ALL errors? You could easily end up with a monster routine larger than the original app.

I think there are some differences in error types.

User Input CONTENT errors, I think, should be handled locally. If an input field requires numeric, and alpha is input, that should be trapped locally - at the procedure level. I do not see the need to pass those to a global error handling routine.

User Input LOGIC errors can be handled at a module level, as normally, after all the information is collected locally (with local error trapping), said information is processed. That is, it is passed along - to the document, or to another module. So, at this oint, the content itself is good, but when parsed logically with other elements, there may be errors. So before the current module finishes there should be final error trapping. This is not "global" really, but it is sort of....

Then finally, I guess there is true global error handling. This handles errors coming out of the modules themselves. It assumes the content of data elements is good (handled locally), the logic within the module is good (handled at module level), but now checks to see if the all the modules TOGETHER (or globally) are good.

Does this makes any sense? Topic is open for discussion.

I absolutely agree that team processing opens up the possibility of unanticipated errors.