Question

I have a large C# code base. It seems quite buggy at times, and I was wondering if there is a quick way to improve finding and diagnosing issues that are occuring on client PCs.

The most pressing issue is that exceptions occur in the software, are caught, and even reported through to me. The problem is that by the time they are caught the original cause of the exception is lost.

I.e. If an exception was caught in a specific method, but that method calls 20 other methods, and those methods each call 20 other methods. You get the picture, a null reference exception is impossible to figure out, especially if it occured on a client machine.

I have currently found some places where I think errors are more likely to occur and wrapped these directly in their own try catch blocks. Is that the only solution? I could be here a long time.

I don’t care that the exception will bring down the current process (it is just a thread anyway – not the main application), but I care that the exceptions come back and don’t help with troubleshooting.

Any ideas?

I am well aware that I am probably asking a question which sounds silly, and may not have a straightforward answer. All the same some discussion would be good.

Answer 1

Exceptions maintain the call stack which you can use to trace the source of the exception unless the exception is rethrown improperly or is swallowed. By the former, I mean something like:

try
{
    //...
}
catch ( Exception e )
{
    //do stuff with exception
    throw e;
}

Instead of :

try
{
    //...
}
catch ( Exception )
{
    //do stuff with exception
    throw;
}

The later maintains the call stack whereas the former does not. In general, code should only catch exceptions that it plans on handling rather than all exceptions. If the code is properly designed this way, then when the top most layer catches the exception, you should have via the call stack the method that started the chain of events.