Typically unmanaged code will throw an exception of type SEHException or
COMException, so if you use
catch(System.Exception ex){}
you will catch both of these since they are both derived from
System.Exception. However, figuring out what the exception means may be
difficult as the mapping from unmanaged exceptions to managed exception
types is not simple or direct, and some exceptions may not roundtrip through
the CLR faithfully.
Using the untyped catch block
catch { ... }
will catch untyped, or non-CLI compliant exceptions. This will catch
exceptions of any type, including untyped exceptions (e.g. numeric values,
such as 0xC0000005). If all your code is managed and CLI-compliant then you
should never get any untyped exceptions as the runtime will translate Win32
exception codes into managed exception types for you. Also, using this form
of a catch block means that you will not have an exception object that you
can programmatically examine.
If you are writing managed code I would not use this - let untyped
exceptions bubble up the callstack. I would instead use
catch(Exception) { ... } // no object - don't care about it
or
catch(Exception ex) {...} ///if you want to use the object.
"Jon Paugh" <an*******@discussions.microsoft.com> wrote in message
news:40****************************@phx.gbl...
Hi,
How do you catch an exception from unmanaged code?
Will
try
{
// unmanaged code
}
catch (Exception e)
{
}
do?
Or do I need:
try
{
}
catch (Exception e)
{
// for managed exceptions
}
catch
{
// for unmanaged exceptions
}
Which exceptions will go to the first catch block and
which will go to the second?
Jon Paugh