Board index » DotNet » non-clr exceptions

non-clr exceptions

DotNet127
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


-
 

Re:non-clr exceptions

The first block will catch any managed exceptions (ie those derived from

Exception), and the second one will catch any other exceptions, though

there's no way to get to the value that was thrown.



--

Eric Gunnerson



Visit the C# product team at www.csharp.net">www.csharp.net

Eric's blog is at weblogs.asp.net/ericgu/">weblogs.asp.net/ericgu/



This posting is provided "AS IS" with no warranties, and confers no rights.

"Jon Paugh" <anonymous@discussions.microsoft.com>wrote in message

Quote
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





-

Re:non-clr exceptions

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" <anonymous@discussions.microsoft.com>wrote in message

Quote
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





-