Where is my c# exception being caught?

Question

I have a .net project with a lot of io exception handling, which I'm trying to trim down. Sometimes mere programming bugs (such as null refs) are being quietly handled by the io catch blocks, which they obviously shouldn't be. I can hunt down where these null refs are being thrown by just turning on the break-when-exception-is-thrown option. However, I'd also like to find out which catch block is greedily eating them when this option is turned off. In other words, when an exception is thrown I'd like to be able to step into, or otherwise identify, the catch-block that's handling it. Is there a simple way to do this?

Set breakpoints? Logging? This doesn't seem very answerable... — BradleyDotNET, Nov 11 '14 at 18:43
I have over a hundred catch blocks. Flipping on and off 100 breakpoints as I go through the debugging process is possible, but not very efficient. Adding 100 logging lines would also be pretty tedious. I'm hoping for something more efficient. — thund, Nov 11 '14 at 18:53
The effort of the 100 logging lines would likely be worth it (especially if you can turn it off later, like in log4Net). Then you know where field exceptions come from. — BradleyDotNET, Nov 11 '14 at 18:58
Sounds like you should be catching `IOException` instead of `Exception` to avoid a catch block handling exceptions that it shouldn't. — juharr, Nov 11 '14 at 19:00
Theoretically yes, but sometimes 3rd party code throws stuff it shouldn't. With time and effort I can certainly tidy up any catch block, but I'd like to know where to focus my efforts first. — thund, Nov 11 '14 at 19:05
Yes, 3rd party libraries that don't throw specific exceptions are very irritating. — juharr, Nov 11 '14 at 19:10
@BradleyDotNET - Yes, logging 100 lines might be the only way to go. Given enough time you can certainly debug anything with print statements. But I was hoping for something quicker and more efficient. — thund, Nov 11 '14 at 19:23
Not sure why this question is "too broad": Either there's some built-in way in VS to quickly see where your exception's being handled or there's not. Apparently there's not. Anyhow, after painstakingly logging all my catch blocks, I found that NONE were actually being called, because some fire-and-forget tasks weren't rethrowing their exceptions, as correctly guessed by Scott Chamberlain [here](http://stackoverflow.com/a/26872462/662694). A quick way to find where/whether an exception's being handled by user code would have made this a much easier issue to debug, which is why I asked. — thund, Nov 11 '14 at 23:43

score 3 · Accepted Answer · answered Nov 11 '14 at 19:02

3

I can hunt down where these null refs are being thrown by just turning on the break-when-exception-is-thrown option. However, I'd also like to find out which catch block is greedily eating them when this option is turned off.

All you need to do is leave on "Break-When-exception-is-thrown" and press your "step-over" button (F10 for me). You may get a few more "First chance exception" message boxes as you bubble up the stack, however eventually this process will bring you in to the catch block that would have caught the exception.

answered Nov 11 '14 at 19:02

Scott Chamberlain

124,994
33
282
431

Right, I'd have thought I could just step over it like you say. But there are many concurrent threads, and the exception thread that gets eaten never seems to get resumed. I'm using VS2013. – thund Nov 11 '14 at 19:15
Concurrent threads should not matter, unless many threads all throw the exception all at once. Stepping over should stay on the thread that threw the exception. – Scott Chamberlain Nov 11 '14 at 19:39
Unfortunately stepping through never brings me to the catch block. After breaking on the buggy code, pressing F10 just returns me to the app. I have Task.Factory.StartNew 's that invoke back onto the uithread. Perhaps that's confusing the debugger. – thund Nov 11 '14 at 20:38
Does `.Result` or `.Wait()` ever get called on these tasks? If not then you are indeed abandoning the exception and they are not getting caught unless you have some kind of global handler set up on `TaskScheduler.UnobservedTaskException`. If you don't have a handler set up the answer to your question "Where is my exception being caught" the answer is "It is not being caught at all". – Scott Chamberlain Nov 11 '14 at 20:45
Yes, that was exactly the problem. Thank you. I had some fire-and-forget tasks whose exceptions I needed to not-forget as described [here](http://stackoverflow.com/a/22864616/662694) for example. – thund Nov 11 '14 at 23:35

score 1 · Answer 2 · answered Nov 11 '14 at 18:58

Set a breakpoint in every catch block, like @BradleyDotNet suggests

Log on every catch block, if you are just debugging you could make use of the System.Diagnostics.Debug class, which is extremely useful in this kind of situation

Also, you could catch specifically Null Exceptions in your code

try
{
    // Buggy code
}
catch (NullReferenceException NullEx)
{
    // Handle NullReferenceException
}
catch (Exception)
{
    // Handle any othr exception
}

Also, you might want to make some major changes, then you could make use of the Exception Handling Application Block of Microsoft's Enterprise Library

Yes, I could do any of these. It's just the sheer number of catch blocks (>100 over ~100 files) that makes this annoying and time-consuming. I'm hoping for a quick way to find the culprit so I can focus my attention there. VS certainly knows which block is catching the exception. I just wish it would tell me. — thund, Nov 11 '14 at 19:18

Lee Harrison · Answer 3 · 2014-11-11T22:19:25.247

0

Be more granular in your exception handling. Rather than use the catch-all 'Exception' type, use a more fine grained type to catch the exceptions you want.

        try
        {
            //do stuff
        }
        catch(FieldAccessException e)
        {
            //Take action on this exception type
            Console.Write(e.Message); 
        }
        catch(NullReferenceException ne)
        { 
             //Take action on this exception type
             Console.Write(ne.Message); 
        }

It's worth noting that if you do want to do this, you cannot use the 'Exception' type before any types that inherit from it.

edited Nov 11 '14 at 22:19

answered Nov 11 '14 at 18:47

Lee Harrison

2,306
21
32

3

You can use `Exception` as long as it's the last one in the catch-list. – C.Evenhuis Nov 11 '14 at 18:57
I agree. However it's a big project that handles a lot of decryption, deserialization, analytics and gui from a lot of sources. Some exceptions that may be thrown by 3rd party code or even by .net itself aren't necessarily well documented, so it's sometimes dangerous to make fine grained assumptions about what they might be. I'm trying to tidy things up in the way you describe, but the top priority is to focus my attention on the catch blocks that are swallowing things they shouldn't. My question is how to efficiently identify which of >100 catch blocks are the culprits. – thund Nov 11 '14 at 19:01
1

In fact you cannot use any exception that is in the inheritance chain of a proceeding exception. So, `ArgumentNullException` cannot be caught after `ArgumentException`, but the reverse is fine. – juharr Nov 11 '14 at 19:03
Good info from @C.Evenhuis and juharr. I have never had to dig that deep into exception handling to realize this. – Lee Harrison Nov 11 '14 at 19:04

Where is my c# exception being caught?

3 Answers3