Re: Handling unhandled exceptions

Tech-Archive recommends: Fix windows errors by optimizing your registry

Bob Altman wrote:
I've written a DLL in "interop" mode (compiled with /clr). This DLL is a wrapper for a managed library. It exposes native C-style entry points, calls into the managed library, and marshals the results (if any) back to the native caller.

Here's the short version of the question: Is there an easy way for my library to catch unhandled managed exceptions (short of putting a try/catch block around each top-level routine in my library)? As I explain below, I tried wiring up the AppDomain.CurrentDomain.UnhandledException event, but that didn't work.

Here's the longer story:

If the managed code called by my library throws an exception that is ultimately unhandled then my library's caller dies a horrible death. That horrible death includes a dialog box that basically tells the user that the program died, but offers little by way of useful information about unhandled exception (like the exception name and the call stack). I want to display my own custom dialog in response to an unhandled exception (before I kill the caller).

Actually, in addition to what others have said, this is not your responsibility. It is the caller's responsibility in turn (and ultimately whoever's responsible for the process as a whole) to handle unhandled exceptions from *your* code. If the caller is/might be a pure C caller that doesn't know about exceptions at all, then it's your job to make sure no exceptions are ever propagated from your functions (at least not those that can be adequately captured in error codes), so exception handlers around every call are entirely appropriate. Otherwise, propagating them may be acceptable, and your client will have to worry about them.

This is also why throwing up a dialog and killing the caller is something you shouldn't do even if you could; the caller may have its own ideas about how to handle exceptions from your library. Only if your library is calling the shots (or is expected to call the shots) could you do something like muck around with .UnhandledException.

If you absolutely, positively must have this level of control, you could always make your DLL purely unmanaged and host the CLR yourself. This will allow you to customize exception handling to your heart's content, but it's not something you should do lightly (for one thing, this will simply not work if your DLL is ever used in a context where the CLR is already hosted, and it obviously makes interacting with managed code a lot less convenient).

--
J.
.

Relevant Pages

  • Re: Some questions about handling exceptions and when to throw them
    ... In the event that a customer can't be ... Possibly even my own exception, ... because the caller should have checked first. ... If GetEmployeeInfo fails, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Some questions about handling exceptions and when to throw them
    ... So in those cases throwing an exception would be a good decision. ... because the caller should have checked first. ... PrinterInfo GetEmployeeDefaultPrinter ... If GetEmployeeInfo fails, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Exception handling help please
    ... > void MyFunc() ... > Then in the caller: ... Second, if you throw an object of a class derived from MyException, ... The copy of the exception object specified in the throw expression ...
    (comp.lang.cpp)
  • Re: Omitting return in non-void function
    ... value of the function call is used by the caller, ... In other other words, NO, as specified by the Standard portion he ... function is equivalent to executing a return statement without an ... The sign draws your attention to the exception. ...
    (comp.lang.c)
  • Re: Example of misusage of exceptions.
    ... >> Skybuck. ... > boolean. ... Instead they throw an exception, telling the caller that they ...
    (alt.comp.lang.borland-delphi)