These are good points, George. With the point about debugging programs, I usually use ON ERROR SYSTEM when I'm debugging as I know it's almost impossible to debug across libraries. But I really want to TRY to create a central error-handling routine, unless it's really a bad idea. Perhaps I should check for certain errors that the routine is meant to handle and others can remain in the calling program instead of library-izing it ALL. There has to be a way to make a very complete elegant error-handing routine that I can use in every program. And of course I've learned enough from you (George) that if it can "function" in a library (pun intended), then that's usually the way to go. But maybe not this time?
I was thinking of having a minimal stub routine in all of the calling programs that sets up all of the variables to pass to the error-handling function (maybe in an array with the first column being the description of the data and the 2nd column being the data such as program name, err, line, etc. I haven't thought about that part much yet.) Then in the function, I'd add to an error log file, possibly display a message to the user about what has happened (if I know), and perhaps have Email monitor send me a message with an attached file that includes all of those values I passed to the function, along with additional information such as STATUS ALL in it. I figured that I could parse the program line on which the error happened to get some more information. I could EXECUTE "LIST "&str$(line)&" >error.line" and then read that back in and analyze it. At that point, the error routine can decide if the calling program needs to exit, continue, or whatever, and send THAT result back to the calling program to deal with.
At least that is my hope. I am going to be implementing such a sweeping set of program changes later this year that I'm anticipating more errors than usual and I would really love to monitor the results. Like you have found, users do NOT like to report errors to me if they can just "get out of them". But we all know that sooner or later, some of those unreported errors can result in data instability (or at least "mystery issues") and when I ask people if they have got any errors, they either can't remember OR they don't want to tell me that they bailed out of the program to solve their problem, so they say no.
When you (George, as well as the rest of you) do your error handling, do you present the user with explanations of the errors (like from the errors.txt files)? Or do you hide that part from them?
Does anyone else use a library to handle errors? If not, why not? Do you have the same issues as George, or are there other reasons? If you aren't using a library, are you duplicating the same error-handling code in every single program then? I guess I'm looking for the best way to have an elegant error-handler that doesn't have to put a ton of code in every program and I'd LIKE it to be a library so I can tweak ONE error handler and have it instantly usable by all programs.