图书馆吞噬了我的例外

Question

I'm using a GUI library like this (pseudocode):

static void ProcessFrame()
{
    // ...
    if(fooWentWrong) throw new FooException();
    if(barWentWrong) throw new BarException();
    // ...
}

static void Main()
{
    GUILib.OnEveryFrame += delegate { ProcessFrame(); };

    try
    {
        GUILib.MainLoop();
    }
    catch(FooException e) // we don't handle BarException
    {
        // handle exception.
    }
}

In other words, GUILib is using inversion of control - its mainloop calls my delegate.

The problem is that GUILib is a legacy lib that catches any exception thrown by OnEveryFrame handlers and just prints it to the console, so my FooException handler is not reached for FooExceptions, and for BarExceptions the Visual Studio debugger doesn't break.

I have made the debugger break for BarExceptions by going to Debug -> Exceptions and checking the break on thrown (and not just "break on onhandled") box for "Common Language Runtime exceptions". This works, but it means VS now breaks when any exception is thrown, even when a handler would have caught it. So I can't use exceptions for non-fatal stuff.

Any better way to do make VS break on my exceptions? I need to somehow work around the library's broken behavior.

BTW, the library is qt4dotnet / Qt Jambi.

Answer 1

You should check if GUILib has an event for 'unhandled' exceptions.

The other approach is triggering the debugger yourself:

     System.Diagnostics.Debugger.Break();

Instead of or in addition to throwing the Exception.

Answer 2

Depending on the exceptions you're interested in, you are probably on the right track by using the Debug->Exceptions dialog, except that you're ticking all the CLR exceptions, so it catches everything.

You can filter it better: click the [+] icon next to the CLR exceptions entry to unfold it and it'll list them all individually, and then you can tick just specific ones - or do it the other way, and tick the main one to enable catching all exceptions in the debugger, then untick a few specific ones (eg MyInternalNotReallyAnExceptionButJustAStatusCodeException* :-). To easily find one or two specific exceptions, click Find... and type in a partial name - for example "NullR" will find the NullReferenceException.

* (And yes, I dislike the idea of using exceptions to report status information - IMHO exceptions should primarily be used to pass on a failure that can't be handled at the site of the throw)

Answer 3

Is it possible to move the exception handling into the delegates? It might end up with a bit of redundant code, but you should be able to refactor the exception handling bodies into a function.