exception handler not called

delphi package - automated exception handling
Post Reply
StephaneGrobety
Posts: 19
Joined: Tue Jul 17, 2018 9:21 am

exception handler not called

Post by StephaneGrobety »

Hello,

I wanted to add a second exception handler in my project:

RegisterExceptionHandler(GlobalSyncExceptionHandler, TSyncType.stTrySyncCallAlways, TExceptPhase.epNotHandledYet); // <-- this is new but doesn't work
RegisterExceptionHandler(GlobalAsyncExceptionHandler, TSyncType.stDontSync, TExceptPhase.epMainPhase); // <- this works and is called during an exception

It seems that, unfortunately, the above does not work: GlobalSyncExceptionHandler is never called and GlobalAsyncExceptionHandler is always called.

Any idea as to why?
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: exception handler not called

Post by madshi »

"epNotHandledYet" is only when you call NewException(). What are you trying to achieve? Does "epQuickFiltering" not work for you? That's probably the phase you want to you.
StephaneGrobety
Posts: 19
Joined: Tue Jul 17, 2018 9:21 am

Re: exception handler not called

Post by StephaneGrobety »

madshi wrote:"epNotHandledYet" is only when you call NewException(). What are you trying to achieve? Does "epQuickFiltering" not work for you? That's probably the phase you want to you.
Thanks,

epQuickFiltering is probably what we are looking for. We need to be able to handle some exception types without going through madexcept and, for convenience, we want this handling to happen in the main thread (it's to catch things like "EExternal" which needs to be explained to the user but do not need to lead to a bug report: they aren't bugs, they are environmental failures).
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: exception handler not called

Post by madshi »

Please be aware, though, that if you use "stTrySyncCallAlways", it is not *guaranteed* that your handler will be called in the context of the main thread. It usually will be, but there's no guarantee. So before you access the VCL, better double check "if GetCurrentThreadId() = MainThreadId".

Alternatively, you can also simply set: "exceptIntf.ShowSetting := ssSimpleBox" in your epQuickFiltering handler. Doing that will show a simple message box instead of the full blown exception handler, and it works in any thread.
StephaneGrobety
Posts: 19
Joined: Tue Jul 17, 2018 9:21 am

Re: exception handler not called

Post by StephaneGrobety »

Please be aware, though, that if you use "stTrySyncCallAlways", it is not *guaranteed* that your handler will be called in the context of the main thread. It usually will be, but there's no guarantee. So before you access the VCL, better double check "if GetCurrentThreadId() = MainThreadId".
That is good to know. I guess that calling TThread.Synchronize from the handler will not help either...
Alternatively, you can also simply set: "exceptIntf.ShowSetting := ssSimpleBox" in your epQuickFiltering handler. Doing that will show a simple message box instead of the full blown exception handler, and it works in any thread.
I'm already doing that but that is not what I'm trying to acheive here: I have some exceptions that might not be caught by any of the internal exception handlers and that indicates that there is an error with the user's environment (best example: EExternalexception EXCEPTION_IN_PAGE_ERROR which is raised - sometimes - when the executable runs from a media that is not available any more and the OS need to read a code page).

I want to write some small, user-understandable documentation to display to the user is such a case without neither completely hiding the original exception nor simply throwing "EExternalexception $C000006" to an unsuspecting accountant :wink:
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: exception handler not called

Post by madshi »

No, TThread.Synchronize will likely not work, either, because if TThread.Synchronize would work, then madExcept would also be able to call your handler in the main thread's context. The main reason why your handler might not be called in the main thread's context is if your main thread is frozen or even gone (crashed).

So the "simple box" is not large enough to hold the text that you want to show to the user? Or what is the reason why the "simple box" doesn't work for you?
StephaneGrobety
Posts: 19
Joined: Tue Jul 17, 2018 9:21 am

Re: exception handler not called

Post by StephaneGrobety »

madshi wrote:No, TThread.Synchronize will likely not work, either, because if TThread.Synchronize would work, then madExcept would also be able to call your handler in the main thread's context. The main reason why your handler might not be called in the main thread's context is if your main thread is frozen or even gone (crashed).

So the "simple box" is not large enough to hold the text that you want to show to the user? Or what is the reason why the "simple box" doesn't work for you?
Both actually:

I have created a framework for injecting Madexcept configuration inside the application (because we actually have more than a hundered different exe that are part of the application) with an abstraction layer (because we were bitten by issue with EurekaLog that forced us to re-release the whole app in a crisis, I had instructions to make sure we could do so with the flip of a swtch).

All that to say that the part that say "in the case of that exception, please just display this dialog instead" and the part that deals with madexcept are not at all in the same location in the code.
(and also: it is too small).


I think I'll just use MessageBoxTimeout if it's thread-safe or even MessageBox if it's not.
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: exception handler not called

Post by madshi »

You can use any win32 API like "Windows.MessageBoxA/W()", but you can't use any Delphi function based on the VCL, because the VCL is not thread safe.

Or you can check if you're in the main thread, and if you are you can use VCL, otherwise please don't.

Or, if you want it perfect, of course you can create your own thread safe dialog using pure win32 APIs instead of the VCL. But that's really painful...
Post Reply