Getting more information than the exception class provides

Need access to native OS errors from .Net? Marshal.GetLastWin32Error() is your friend « C# Hacker - The Rambling Coder

Sat, 20 Jun 2009 16:18:27 GMT

PingBack from http://www.csharphacker.com/technicalblog/index.php/2009/06/20/need-access-to-native-os-errors-from-net-marshalgetlastwin32error-is-your-friend/

re: Getting more information than the exception class provides

Jeff LeBert — Sat, 20 Jun 2009 18:04:19 GMT

I use Marshal.GetHRForException(e) instead. I was using FileStream and WebClient to open IO streams. Both throw completely different exceptions for the "same" issue. I created a function that would look at the exception and tell me if it was a file not found, authorization, sharing issue, etc. Obviously GetLastWin32Error wouldn't work because I wanted to look at a specific exception.

Getting more information than the exception class provides - CLR Team Blog

DotNetShoutout — Sun, 21 Jun 2009 00:44:37 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

re: Getting more information than the exception class provides

Dmitry Zaslavsky — Sun, 21 Jun 2009 20:57:18 GMT

int error = Marshal.GetLastWin32Error();

Is better then parsing text of course. However it relies on the fact that at least BCL itself will never call another API which will reset the code.

This effectively relies on the internals of BCL not to change and it also would be a possible breaking change in the future.

For example you may decide to call some other APIs to get more information about the source of the issue.

I wouldn't recommend this solution either.

In short, I think Marshal.GetLastWin32Error() is just a tiny bit better than parsing text.

Full solution is for BCL to subsclass exceptions or at the very least to expose Win32Code on the exception thrown

re: Getting more information than the exception class provides

Andrei Rinea — Sun, 21 Jun 2009 21:08:24 GMT

To nitpick a little, in the code sample since the first FileStream result is not used anywhere else in the code in Release compilation it could be collected and finalized (and therefore the file closed).

I know it is just a simple code sample + it's very unlikely to have the file closed by the time the second File.Open gets called.

I just could not resist nitpicking :)

re: Getting more information than the exception class provides

Oleg Mihailik — Mon, 22 Jun 2009 01:49:18 GMT

Certainly if you want to differentiate errors, you create inherited exception class. One would have thought CLR team knows the guidelines of programming CLR.

I cant wait to laugh when you realize Win32Code is not detailed enough for some scenarios, and you will add one more differentiator like Win32SubCode. Then Win64SubCode, Ole32Code and whatelse.

And if you're wary of changing class hierarchies, didn't you already add Dictionary-typed property to Exception?

re: Getting more information than the exception class provides

Oleg Mihailik — Mon, 22 Jun 2009 02:19:44 GMT

>> I know it is just a simple code sample + it's very unlikely to have the file closed

>> by the time the second File.Open gets called.

Well, since the first FileStream instance is not cached in a variable, it is as likely to get nicked in Debug mode as in Release.

I do not think that is a nitpicking at all. It is rather likely the whole problem of requiring Win32Code was in fact sucked out of that bizarre code style. Let me explain.

Imagine, somebody uses File.Open this childish way:

var f = File.Open(...);

f.Read(...);

f.Close();

Obviously, sometimes File.Open may fail by host of practical reasons: USB stick is pulled out in the middle of write, CD is too scratchy, network gone dead, actual intrinsic code logic error not related to I/O. Nobody really cares about the reason in that situation: you just can't recover.

However, that file is left opened. That is where 'derivative' error started to happen when accessing the same path. If Garbage Collector was lazy enough to not clean the file handle in time.

And only that 'derivative' error is recoverable. Surely, if you sit and wait long enough, GC breaks in, start collecting dead bodies and switching off life machines of those poor comatose guys who do not have living relations or next-of-kin to remember them. Alas, waiting may help when you've been dirty not cleaning up your own stuff, and there's GC willing to clean anyway.

Why don't I think that file sharing issue is genuine need? Because in real life blocked file

is as much likely to get released, as scratched CD get read be second attempt, or network get reconnected after you walk out of the underground walkway. So if you genuinely do want to do several File.Open attempts, you would want to do that not only for blocked shared file.

I know that's kind of psychic debugging, but common sense and logic give strong suggestion I've guessed it right.

In general, there's no justified reason to have this feature. Of course there's 'dirty coding' reason, but should BCL get messy and more complex to help somebody hack their way through bugs? Don't think so.

If they do want to keep to their muddy paths, why don't they learn how to use PInvoke and get files opened with kernel32.dll/CreateFile?

re: Getting more information than the exception class provides

Peter Ritchie — Thu, 25 Jun 2009 18:20:13 GMT

It would be nice if the Framework used HResult consistently. Sometimes the framework uses HResult to communicate the last win32 error, sometimes it doesn't.

It would actually be more useful if the Framework used IOException consistently, i.e. don't use IOException for invalid-operation-like exceptions (e.g. Directory.Move when source and dest don't have same root. That's not an IO exception...)

re: Getting more information than the exception class provides

qs7000 — Mon, 14 Sep 2009 13:49:44 GMT

Let me direct your attention to the following feedback entry in Connect:

"IOException should provide more differentiated error information"

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=94306

What surprised me is its age: it was created in 2005, and nothing seems to have happened since.

Please add some new IOException-derived types to .Net 4.0 - this is long overdue (especially SharingViolationException)!