Why not use the standard try catch blocks?

i.e.

Try
    ' Whatever
Catch ex as InvalidOperatationException
    msgbox(" Invalid Op!")
Catch ex as FileIOException
    msgbox("File IO Exception!")
Catch ex as Exception
    ' Grabs all the other exception (well, for the most part)
   msgbox(ex.message)
End Try

Thanks,

Seth Rowe

I may be wrong but I don't believe there's a way to do this.  You
could try calling the Win32 method GetLastError() but I don't think
there's any guarantee that it wasn't reset to something else
between the file access and when you got the exception.

This is a nice concept but personally I've never found this type of
error handling that useful plus it can be time consuming and difficult
to keep up with all of the lower level error codes that may come back.
In addition it may be so far removed from your original request that
it's impossible disambiguate between multiple scenarios.  What if
some virus scanner is holding on to a lock to that file and when the
user tries to open it your message tells them to close it.  Then
they'll just get annoyed with your app because they don't have it
open.  That later will just get them annoyed with windows in general
- which is always better.
Personally I feel that higher level processes should provide more
general type errors.  For example just a "Failed to open file" with
the option to look at the details which would be "The process cannot
access the file 'C:\Documents and
Settings\LBN\Desktop\Proforma.xls' because it is being used by another
process."

You should handle exceptions you know about explicitly.  If you expect you
might get a general error (i.e. an error you don't know about or didn't
think about), then you catch it with a standard "catch all".  It is often
useful to put the catch all exception handler as a top level handler in your
main method, especially if you intend to terminate the program when it
happens:

Now as for your French users, in general users won't have a clue what the
exception message returned means, no clue whatsoever, even the English
speaking ones (most of them actually) especially in the context of your
running program, so there is no need to provide translations of those
messages at all.  What you DO need to do, is to provide some kind of message
box/logging facility so the user can at least copy the message to the
clip-board to send to your support.

In the general case, my software operates with different error levels, the
highest is "Exception" (SystemFatal), given that if I don't know what the
error is, I have no confidence that the software can continue without
borking up something else.  For example:

Public Enum ErrorClassEnum

   OK ' Success
   Fail 'In a multiple iteration operation, fail the iteration, not the
whole operation
   Fatal 'Terminate the entire operation
   SystemFatal 'Terminate the program
   Cancel 'Terminate the entire operation, don't display an error message

End Enum

the "Ex As Exception" is SystemFatal for me, whereas the SqlException might
be SystemFatal, Fatal or Fail, depending on what the error number is.   Many
SystemFatal exceptions are caused by bad programming rather than real system
errors.  For example, divison by zero, null-reference exception, etc.  You
can code defensively to avoid many of these ever happening.

Pieter,

The trick is to put several individual try/catch blocks around small
blocks of code. If you need that finely-grained control, a "block" may
be a single method call. RTFM and decide what you need to catch.

For instance, on the StreamReader(string) constructor, there are 5
possible exceptions that can be thrown. Based on context, each one can
mean only one thing. Do something like:

// Get string strFilename from user.
StreamReader myStream;
try
{
 myStream = new StreamReader(strFilename);
}
catch (ArgumentException)
{
 // The filename string was empty.
}
catch (ArgumentNullException)
{
 // The filename string was null.
}
catch (FileNotFoundException)
{
 // At this point, we're sure that the filename string was valid, but
there's
 // no valid file at the location it points to on the filesystem.
}
catch (DirectoryNotFoundException)
{
 // At this point, we're sure that the filename string was valid, but
part
 // of the path that it refers to is invalid.
}
catch (IOException)
{
 // At this point, we know that the format of the filename is
incorrect.
}

Similarly, just about every operation involving any I/O has a similar
canonical exception list. See the documentation and figure out exactly
what to catch and what it means for the particular functions you need.

I believe it's bad coding style to *need* to catch all of those
exceptions in most cases. A much better way to do this is to
pre-validate (contract check) every variable. For instance, the
following code:

if (strFilename == null || strFilename == String.Empty)
 // Break out: the filename is invalid

will take care of the first two exceptions. File.Exists() will tell you
if the file exists or not and save you catching the other three
exceptions. No exceptions are thrown -- throwing an exception is a
highly costly process -- and you get the same information. It also has
the added benefit of saving the exceptions for real exception cases.
For instance, if the user specifies a file, then between when you
capture the filename and when you try to do something with the file,
they unplug the USB device that the file is on, that's a real
exception. It's probably one you can't handle at the level of this
method, so it should get bubbled up to the main thread and handled
there, probably by telling the user, "you've done something I didn't
expect and can't correct."

Stephan