>Hello Martina,
>
>Thank you for the reply. I'm not sure I understand... The code you are showing captures the current ON ERROR setting, and then restores it (assuming there was an ON ERROR setting). I understand that but what I'm trying to do is: Within the PROCEDURE Error have code that will do some processing (e.g., logging specific to what that object does), then somehow "bubble up" the error so the ON ERROR set at application launch will process it and do its usual logging of errors in the application-wide error table, and handle any automated recovery.

As for logging, why don't you call your logger directly from the .error() method?
For automated recovery, it depends on what it's trying to do.

For such cascaded error handling, and error handling in general, I've found early on that .error() method is the least usable, actually generally the worst handler, so I learned to avoid it, and I think I haven't written a line in it in the last 20 years. I think you're finding its downsides now. I found it simpler to have a general try-catch wrapper around the Read Events statement, which would be the last line of defense for anything that the local handlers miss.