Note that there are some explanatory texts on larger screens.

plurals
  1. POThrowing a Win32Exception
    text
    copied!<p>I've been writing a lot of code recently that involves interop with the Win32 API and have been starting to wonder what's the best way to deal with native (unmanaged) errors that are caused by calls to Windows API functions.</p> <p>Currently, the calls to native functions look something like this:</p> <pre><code>// NativeFunction returns true when successful and false when an error // occurred. When an error occurs, the MSDN docs usually tell you that the // error code can be discovered by calling GetLastError (as long as the // SetLastError flag has been set in the DllImport attribute). // Marshal.GetLastWin32Error is the equivalent managed function, it seems. if (!WinApi.NativeFunction(param1, param2, param3)) throw new Win32Exception(); </code></pre> <p>The line that raises the exception can be equivalently rewritten as such I believe:</p> <pre><code>throw new Win32Exception(Marshal.GetLastWin32Error()); </code></pre> <p>Now, this is all well in that it throws an exception appropriately containing the Win32 error code that was set as well as a (generally) human-readable description of the error as the <code>Message</code> property of the Exception object. However, I have been thinking that it would be advisable to modify/wrap at least some, if not all, of these exceptions so that they give a slightly more context-oriented error message, i.e. one more meaningful in whatever situation the native code is being used. I have considered several alternatives for this:</p> <ol> <li><p>Specifying a custom error message in the constructor for <code>Win32Exception</code>.</p> <pre><code>throw new Win32Exception(Marshal.GetLastWin32Error(), "My custom error message."); </code></pre></li> <li><p>Wrapping the <code>Win32Exception</code> in another Exception object so that both the original error code and message are retained (the <code>Win32Exception</code> is now the <code>InnerException</code> of the parent exception).</p> <pre><code>throw new Exception("My custom error message.", Win32Exception(Marshal.GetLastWin32Error())); </code></pre></li> <li><p>The same as 2, except using another <code>Win32Exception</code> as the wrapper exception.</p></li> <li><p>The same as 2, except using a custom class derived from <code>Exception</code> as the wrapper exception.</p></li> <li><p>The same as 2, except using a BCL (Base Class Library) exception as the parent when appropiate. Not sure whether it's even appropiate to set the <code>InnerException</code> to the <code>Win32Exception</code> in this case (perhaps for a low-level wrapper but not a higher-level/abstracted interface that doesn't make it obvious that Win32 interop is happening behind the scenes?)</p></li> </ol> <p>Essentially what I want to know is: what is the recommended practice on dealing with Win32 errors in .NET? I see it done in open-source code in all sorts of different ways, but I was curious whether there were any design guidelines. If not, I'd be interested in your personal preferences here. (Perhaps you even use none of the above methods?)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload