Err.Number is always = 5

  • Thread starter Thread starter Kirk
  • Start date Start date
K

Kirk

I have several routines that use the Try-Catch-EndTry method. When an
error occurs in one of these routines, I display it like this:

Catch ex As Exception
MsgBox("Error #" & Err.Number & ": " & Err.Description)
Exit Function
End Try

For some reason, no matter what the error is, the Err.Number is ALWAYS
"5". I have generated different errors and while the Description
changes, the error number never does.

I am sure I am missing something simple & I would appreciate any
suggestions.

Thanx!
 
Use the properties of the Exception object, ex. Your code is querying
the Err object which may not be reliable for all exceptions.

Err.Number = 5 means "Access is denied."
 
Thanks a lot for your quick response.

I tried to use the properties of the Exception object, but I could not
find one that shows a unique identifier (like an error number). I
would like to have this number so I can handle different errors in
different ways. For example, if the error code equalled "5"
(indicating an access error), I could show a more "user friendly"
message in addition to the generic/technical one.

Specifically, which property would contain this? I tried
InnerException, Source, GetBaseException, and TargetSite, but none of
these was what I was looking for.

On a related note, can anyone direct me to a listing of the Err.Number
descriptions?

Thanx again!
 
Kirk said:
Thanks a lot for your quick response.

I tried to use the properties of the Exception object, but I could not
find one that shows a unique identifier (like an error number). I
would like to have this number so I can handle different errors in
different ways. For example, if the error code equalled "5"
(indicating an access error), I could show a more "user friendly"
message in addition to the generic/technical one.

Specifically, which property would contain this? I tried
InnerException, Source, GetBaseException, and TargetSite, but none of
these was what I was looking for.

On a related note, can anyone direct me to a listing of the Err.Number
descriptions?

Thanx again!

Generally to do that you would catch multiple exception types, rather than a
single generic exception type
 
Kirk,

I don't believe exceptions have a specific number associated with them
(although the exception's HResult property might be useful).

Instead, you can catch specific exceptions and supply your own user-friendly
message. Here is an example that catches various exceptions and supplies an
application-specific message:

Catch ex As InvalidCastException
MsgBox("Input values must be numbers", MsgBoxStyle.Exclamation,
"Input Error")

Catch ex As DivideByZeroException
MsgBox("The number of donors cannot be zero",
MsgBoxStyle.Exclamation, "Input Error")

Catch ex As Exception
MsgBox(ex.Message, MsgBoxStyle.Critical, "Error")

End Try

Kerry Moorman
 
Kerry,

Thanks for your detailed response! Your example code worked well for
me. I guess I was still stuck in the "old school" mindset of capturing
errors by identifying the unique error numbers. Also, I did not really
understand how the exception Catch terminology worked.

Thanks again.
 
Kirk said:
I tried to use the properties of the Exception object, but I could not
find one that shows a unique identifier (like an error number).

That's because you don't [iften] need one. The *Type* of the
Exception itself tells you what went wrng, which is why you tend to
see Catch blocks like this

Try
SomethingDodgy()
Catch ex as ReallySpecificTypeOfException
Recover()
Catch ex as SomeOtherTypeOfException
Giveup()
Catch ex as EvenMoreGenericException
Throw

' or, possibly, even
Catch ex as System.Exception
If TypeOf ex Is ArgumentException Then
OhDearYouDidSomethingWrong()
Else
Throw
End If
End Try

Notice that your Catch'es have to be "in order", catching the
"smallest" Exception first, i.e. the one "most" derived from
System.Exception. Check the Class hierarchy for each Exception
in MSDN; the /fewer/ levels it is away from System.Exception, the
earlier you should code to catch it. Beware:

Try
Catch ex as Exception
' /Always/ arrives here
Catch ex as ArgumentException
' *Never* arrives here
End Try

BTW, *some* Exceptions, like the COMException, /do/ have a
numeric ErrorCode property (which, inthis case, holds the errant
HResult), but you only get these thrown by methods that "call out"
to COM. Managed Code doesn't do this so no error "number" is
necessary.

HTH,
Phill W.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top