C# try/catch nightmare

Question

I have a application with similar code (not written by me)

try
{
    EnumerateSomeCoolHardwareDevice();
}
catch (Exception ex)
{

}

UPDATE - This is .NET C# & EnumerateSomeCoolHardwareDevice() is using SerialPort?

I know how bad this code is but it works like this for a reason!

My question thou: I can see that it crashes somewhere in the EnumerateSomeCoolHardwareDevice(); but it doesn't get caught by the Catch (...) - It just crashes with the send report dialog! This also currently only happen in the release build... Is their ANY reason why my exception will NOT be caught by the catch (...)?

Answer 1

My guess is that you're not getting an Exception in your language/framework but rather EnumerateSomeCoolHardwareDevice() does weird things that simply cause the OS to kill your process. Remember that hardware details are abstracted by frameworks like Java and .NET, so whenever you do something with hardware directly, you're probably relying on unmanaged resources ... and whatever goes wrong there can kill you, catch or not.

Answer 2

There may be a try..catch inside EnumerateSomeCoolHardwareDevice().

If the exception is caught and handled there, the outer exception won't be hit unless the Exception is thrown again.

Answer 3

In .NET catch (Exception ex) will only catch .NET exceptions, not native exceptions.

This question (catching native exceptions in C#) may help.

Answer 4

(Assuming Java) Both Error and Exception are subclasses of Throwable. If there is an assertion failing in EnumerateSomeCoolHardwareDevice() for example you will get an Error.

Answer 5

Assuming .NET, if EnumerateSomeCoolHardwareDevice uses Win32 methods via PInvoke (to access the hardware) and an error occurs, most Native methods return an error code. If that error code is not handled, and another native method is called anyway (perhaps with empty out parameters from the failed call), a serious native error (such as bad memory access or something similar) can cause a straight program crash, no exception thrown.

Answer 6

If it is only happening on the production machine and not the dev machines then it could be down to DLL mismatches. Double check ALL the referenced DLLs and frameworks are the same version.

Secondly if the error is not being thrown by the EnumerateSomeCoolHardwareDevice() then it will crash the app as there is no way for the exception to get back up the stack (or thats my understanding of try/catches) in my experience this has happened to me before.

Lastly, the microsoft error report usually allows you to inspect what will be sent to MS, this should let you see where the error happened and why (assuming it has readable information within it).

Check the Event Viewer as the error should also be logged there, and normally provides an invaluable source of detail regarding the error and with a bit of digging through the error listed there you should be able to trace the fault.

Answer 7

My guess is that there's a stack overflow happening. The .NET VM simply shuts down Release build processes that encounter a stack overflow, no CLR exceptions thrown. There's probably an internal try / catch inside that function that catches StackOverflowException one way or other, that's why it's not propagating to your code in Debug builds either.

The easiest way to figure out what's going on is by making a debug build, attaching a debugger and instructing the debugger to break before any exceptions are thrown (in Visual Studio, Debug/Exceptions and tick "Thrown" for "Common Language Runtime Exceptions" and possibly other ones as well, in cordbg.exe "catch exception")

Answer 8

If it is crashing madly and is using a SerialPort object then it is probably because at some point it skips onto a background thread and an exception happens here. IIRC the .DataReceived event or however you get information back from a serial port returns data on a background thread. Should an exception be thrown in this routine then the entire application will bail.

Find the background thread and put some exception handling round it.

Answer 9

One possible reason would be if the EnumerateSomeCoolHardwareDevice() function uses threading. If an exception is thrown in a thread and isn't handled within it's thread then it can crash an application. This simple app can demonstrate what I mean:

    public static void testThread()
    {
        throw new Exception("oh god it's broken");
    }

    static void Main(string[] args)
    {
        try
        {
            Thread thread = new Thread(testThread);
            thread.Start();
            Console.ReadKey(); //Just to make sure we don't get out of the try-catch too soon
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
    }

If you run that the app will crash and burn rather than catching the exception as you might expect.

Answer 10

Have you tried the attribute

assembly:RuntimeCompatibility(WrapNonExceptionThrows = true)

That should wrap any non-.Net exceptions into System.Exception so it will be catched in your code.

Answer 11

If you are in .Net version 1.1 use a no parameters catch block like

catch{
...
}

Prior to .Net 2.0 there could be native exceptions that do not derive from System.Exception.

Also hook to appdomain unhandled exception event and see what happens.

Answer 12

What types of exception have you seen behaving in this way? Do you have a list of them?

Some exceptions will keep propgating up the call stack, even if they've been caught in a catch block, such as ThreadAbortException.

Others are essentially unhandleable, such as StackOverflowException or ExecutionEngineException.

If it is one of these (or some others I have probably missed), then the behaviour is probably as expected. If it is some others, then a deeper look with more information will be necessary.