How to check which IO.Exception it was?

[André Nogueira]

Hi there!
I am developing an Windows Explorer-like application that will tell you the
size of any folder.
But so far I have come across some problems.
For instance, you may not have access to all folders in NTFS drives, or a
floppy disk may not be in the drive when I access it.
The question is, how can I check in a Try Catch statement the precise error
that was returned?
Isn't there an error number? I could check the ex.Message but I believe that
isn't the best way to do it...
How can I check the error number or something?

Thank you!

 

[Herfried K. Wagner [MVP]]

I am developing an Windows Explorer-like application that will tell you the
size of any folder.
But so far I have come across some problems.
For instance, you may not have access to all folders in NTFS drives, or a
floppy disk may not be in the drive when I access it.
The question is, how can I check in a Try Catch statement the precise error
that was returned?
Isn't there an error number? I could check the ex.Message but I believe that
isn't the best way to do it...
How can I check the error number or something?

Take a look at the exception's 'HResult'.

 

[Jay B. Harlow [MVP - Outlook]]

André,
Have you tried checking for one of the exception classes that inherit from
IOException?

System.Object
System.Exception
System.SystemException
System.IO.IOException
System.IO.DirectoryNotFoundException
System.IO.EndOfStreamException
System.IO.FileLoadException
System.IO.FileNotFoundException
System.IO.PathTooLongException

Remember that most exceptions have a specific Exception class that you can
check for.

Try
' do something
Catch ex As DirectoryNotFoundException
' do something because the directory was not found
Catch ex As FileNotFoundException
' do something because the file was not found
Catch ex As PathTooLongException
' do something because the path was too long
Catch ex As IOException
' do something because a different IO exception occurred
Catch ex As Exception
' generally I would not catch Exception here
' rather I let my global exception handlers deal with
System.Exception
' included more to show proper order of catching exceptions...
End Try

When you catch exceptions as above, be certain to catch the more specific
(most derived) exceptions first, and catch more general (base) exceptions
last.

NOTE: not having access to an NTFS drive may be a security exception instead
of an IO exception, I have not tested it to see which is raised. I either
check my exception log (that my global exception handler wrote) or I
temporarily add a "Catch ex As Exception" and look at what exception was
caught. Instead of temporarily adding a "Catch ex As Exception", the
debugger can break on the exception so you can identify it.

Hope this helps
Jay