Finding which exceptions a function throws

[=?Utf-8?B?QnJpYW4gTmljaG9sc29u?=]

How do I know which exceptions a function throws? In my application, I make
a call to DirectoryInfo.GetDirectories("\\NetworkPath\Path") . I check for
System.IO.DirectoryNotFoundException and Security.SecurityException (which I
found in the Object Browser with VS2005). If Path is invalid, the block
catches System.IO.DirectoryNotFoundException as expected. However, if
NetworkPath is invalid, it instead throws a System.IO.IOException, which I
didn't see in the Object Browser. What documentation describes this behavior?

[=?Utf-8?B?S2VycnkgTW9vcm1hbg==?=]

Brian,

Unlike Java, .Net does not require that a method list all the possible
exceptions that it might throw.

As far as I know, your best bet is to always catch a plain old exception as
a backstop in case the ones you are explicitly handling are not in fact the
only ones that can get thrown.

Kerry Moorman
"Brian Nicholson" wrote:

How do I know which exceptions a function throws? In my application, I make
a call to DirectoryInfo.GetDirectories("\\NetworkPath\Path") . I check for
System.IO.DirectoryNotFoundException and Security.SecurityException (which I
found in the Object Browser with VS2005). If Path is invalid, the block
catches System.IO.DirectoryNotFoundException as expected. However, if
NetworkPath is invalid, it instead throws a System.IO.IOException, which I
didn't see in the Object Browser. What documentation describes this behavior?

[rowe_newsgroups]

On Jul 24, 3:04*pm, Brian Nicholson
<[e-mail]:

How do I know which exceptions a function throws? *In my application, Imake
a call to DirectoryInfo.GetDirectories("\\NetworkPath\Path") . *I check for
System.IO.DirectoryNotFoundException and Security.SecurityException (which I
found in the Object Browser with VS2005). *If Path is invalid, the block
catches System.IO.DirectoryNotFoundException as expected. *However, if
NetworkPath is invalid, it instead throws a System.IO.IOException, which I
didn't see in the Object Browser. *What documentation describes this behavior?

I have noticed that many of the comments for the class members list
the exceptions that it might throw, but even if it does I wouldn't
trust it as fool proof.

Also, the general rule of thumb is to not catch an exception you can't
do something with. With that said, if you don't plan on telling your
user exactly what happened (or doing something else with the different
types) then I would say to just go with "Catch ex As Exception"

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/

[=?Utf-8?B?QnJpYW4gTmljaG9sc29u?=]

>

I have noticed that many of the comments for the class members list
the exceptions that it might throw, but even if it does I wouldn't
trust it as fool proof.

Also, the general rule of thumb is to not catch an exception you can't
do something with. With that said, if you don't plan on telling your
user exactly what happened (or doing something else with the different
types) then I would say to just go with "Catch ex As Exception"

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/

Thanks for the tip -- I was asking because I was trying to catch all the
exceptions and display user-friendly messages instead of the default ones
inside of each catch block. Is there a better way to go about doing this?

[rowe_newsgroups]

Is there a better way to go about doing this?

Not really.

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/

[Andrew Morton]

Brian Nicholson wrote:

How do I know which exceptions a function throws? In my application,
I make a call to DirectoryInfo.GetDirectories("\\NetworkPath\Path") .
I check for System.IO.DirectoryNotFoundException and
Security.SecurityException (which I found in the Object Browser with
VS2005). If Path is invalid, the block catches
System.IO.DirectoryNotFoundException as expected. However, if
NetworkPath is invalid, it instead throws a System.IO.IOException,
which I didn't see in the Object Browser.

How about checking for Directory.Exists first?

Andrew

[=?Utf-8?B?U2l2?=]

Brian,
I know this won't hide the user from the slightly unfriendly messages you
get from VB.NET but it might produce slightly tidier results for those
unexpected errors:

In your main module or at the top of your form declare a static variable as
follows:
Public Const Support As String = "Your Name and Contact Number"
Public Const AdminContact As String = "User Admin Name"
Public Const NNL As String = vbCrLf & vbCrLf

Public Sub PEH(ByVal ProcedureName As String, ByVal FormName As String,
ByVal ErrorMessage As String)
Dim Msg As String = "WARNING: An error has occured in the " &
ProcedureName & " procedure in the "

Try

Msg += FormName & " form or module. The error message returned
is as follows:" & NNL
Msg += ErrorMessage & NNL
Msg += "Please make a note of the above error and advise " &
AdminContact & ", who will "
Msg += "advise you what to do."
MessageBox.Show(Msg, H, MessageBoxButtons.OK,
MessageBoxIcon.Information)

Catch ex As Exception

Msg = "WARNING: An error has occurred in the error handler
itself??" & NNL
Msg += "Please contact " & Support & " as this shouldn't happen
normally!" & NNL
Msg += "Click ""OK"" to end the application."
MessageBox.Show(Msg, H, MessageBoxButtons.OK,
MessageBoxIcon.Information)
End

End Try

End Sub

In your individual catch blocks within Subs and Functions that might throw
unexpected errors do this:
Catch ex As Exception

PEH("NameOfSuborFunc", "NameOfFormOrModule", ex.Message)
End Try

If the developer changes you can change the Const for Support and everwhere
the error handler occurs will automatically quote the new deveoper and also
if your client who uses the application changes who is the administrator you
just change the AdminContact and likewise their details change automatically
everywhere.

Hope this is of some use.

Siv

--
Martley, Near Worcester, UK
"Brian Nicholson" wrote:

I have noticed that many of the comments for the class members list
the exceptions that it might throw, but even if it does I wouldn't
trust it as fool proof.

Also, the general rule of thumb is to not catch an exception you can't
do something with. With that said, if you don't plan on telling your
user exactly what happened (or doing something else with the different
types) then I would say to just go with "Catch ex As Exception"

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/

Thanks for the tip -- I was asking because I was trying to catch all the
exceptions and display user-friendly messages instead of the default ones
inside of each catch block. Is there a better way to go about doing this?