Error Handling - custom "Throw"?

[bill salkin]

I'd like to create a custom error handler like this in
VB.NET:

....
try
...
Throw ("Lender Name not in table")
....

catch ("Lender Name not in table")
' handle excpetion, put up nice user message, etc.
catch
end try

Is something like that possible in VB.NET?

Note that the error is not one of the standard exceptions
that .NET exposes so there is no obvious way to "catch"
it. The error relates to the business logic of the app. (I
don't know if one can "goto" a catch clause -- but I don't
want to code it that way).


TIA,

Bill

 

[Tom Spink]

Hi Bill,

It certainly is!! Just create a class that derives from "Exception"...

' ===
Public Class LenderNameException
Inherits Exception

Public Sub New()
MyBase.New()
End Sub

Public Sub New(ByVal Message As String)
MyBase.New(Message)
End Sub

End Class
' ===

and then...

..
..
..
Try
...
Throw New LenderNameException("Hurrah!!")
...
Catch ex As LenderNameException
...
End Try
..
..
..

--
HTH,
-- Tom Spink, Über Geek

Please respond to the newsgroup,
so all can benefit

" System.Reflection Master "

==== Converting to 2002 ====
Remove inline declarations

 

[Armin Zingler]

I'd like to create a custom error handler like this in
VB.NET:

...
try
...
Throw ("Lender Name not in table")
....

catch ("Lender Name not in table")
' handle excpetion, put up nice user message, etc.
catch
end try

Is something like that possible in VB.NET?

Note that the error is not one of the standard exceptions
that .NET exposes so there is no obvious way to "catch"
it. The error relates to the business logic of the app. (I
don't know if one can "goto" a catch clause -- but I don't
want to code it that way).

Write your own class derived from System.Exception.

 

[Herfried K. Wagner [MVP]]

I'd like to create a custom error handler like this in
VB.NET:

...
try
...
Throw ("Lender Name not in table")
....

catch ("Lender Name not in table")
' handle excpetion, put up nice user message, etc.
catch
end try

Is something like that possible in VB.NET?

Note that the error is not one of the standard exceptions
that .NET exposes so there is no obvious way to "catch"
it. The error relates to the business logic of the app. (I
don't know if one can "goto" a catch clause -- but I don't
want to code it that way).

\\\
Public Class FooException
Inherits Exception

Public Sub New(...)

 

[Rob Teixeira [MVP]]

Just an FYI...

Non-fatal and application-specific custom exceptions should inherit from
ApplicationException, not Exception.
It's a good convention to follow and allows component consumers to do the
following :

Catch ex As Exception
MsgBox("An unexpected error occurred. Operation cannot be completed")
...
Catch ex1 As ApplicationException
MsgBox(ex1.Message)
End Try

-Rob Teixeira [MVP]

 

[bill salkin]

Thanks to everyone for their replies!

Rob,

Thanks for your reply but I found this gem:

"[Note: ApplicationException does not provide information
as to the cause of the exception. In most scenarios,
instances of this class should not be thrown. In cases
where this class is instantiated, a human-readable message
describing the error should be passed to the constructor.]"

Since I need to know the source of the application error I
may just have to do what the other responders recommended.
(ApplicationException doesn't seem to do the trick.)


Bill

 

[Rob Teixeira [MVP]]

What this is referring to is that ApplicationException by itself tells you
nothing. Rather than throwing an instance of ApplicationException itself,
you are expected to create custom exception classes that inherit from
ApplicationException (read the paragraph above the one you posted). For
example:

<Serializable()> _
Public Class InvalidFinancialSummaryException
Inherits ApplicationException

'REM class code here, including custom Message

End Class

A Catch statement that captures ApplicationException will catch the
InvalidFinancialSummaryException and any other exception that derrives from
ApplicationException. It's a way to organize, categorize, and classify
Exception handling.
By the way, I did make an error in my previous post - the
ApplicationException should be handled BEFORE the generic Exception. It's
important to handle from most specific to most generic.

Here's the quote from the section on creating user-defined exceptions from
the MSDN Exception Handling Fundamentals:
"Do not derive user-defined exceptions from the Exception base class. For
most applications, derive custom exceptions from the ApplicationException
class."

-Rob Teixeira [MVP]

Thanks to everyone for their replies!

Rob,

Thanks for your reply but I found this gem:

"[Note: ApplicationException does not provide information
as to the cause of the exception. In most scenarios,
instances of this class should not be thrown. In cases
where this class is instantiated, a human-readable message
describing the error should be passed to the constructor.]"

Since I need to know the source of the application error I
may just have to do what the other responders recommended.
(ApplicationException doesn't seem to do the trick.)


Bill

 

[Mike]

Try Raise error.
Also you might want to look at www.TechnicalVideos.net they got a
bunch of great stuff on there.

 

[Jay B. Harlow [MVP - Outlook]]

Rob,
You may want to use:

Catch ex As ApplicationException
MsgBox(ex.Message)
Catch ex As Exception
MsgBox("An unexpected error occurred. Operation cannot be completed")
...
End Try

Seeing as Exception is the root class, if you put "Catch ex As Exception"
first, that catch will be the one used, and "Catch ex As
ApplicationException" will never be entered! C# is nice enough to give us a
warning when you reverse the classes... I'll have to remember to try it in
Whidbey...

Also you can reuse the same variable in each catch clause, no need for ex,
ex1, ex2...

Hope this helps
Jay

 

[Rob Teixeira [MVP]]

Yep, I caught the ordering error right after posting it, and posted another
response with the correction.
The name of the variable itself doesn't hold much consequence. It's
considered block-level scope, so the compiler will create separate stack
allocations for each regardless of what they are called. Kind of like
re-using I in two different for loops produces local variables v_5 and v_6
(as examples).
All in all, it's a matter of taste, and in my case it probably has something
to with old habits about ambiguous symbols in the reading of the code itself


-Rob Teixeira [MVP]

 

[Tom Spink]

Hi, Fair enough... Good point, but then...

....
Catch ex As ApplicationException

If TypeOf ex Is MyAppExp1 Then
' Foo
ElseIf TypeOf ex Is MyAppExp2 Then
' Bar
ElseIf TypeOf ex Is MyAppExp3 Then
' Baz
End If

End Try

Yuk. Much simpler, however...

....
Catch ex1 As MyAppExp1
' Foo
Catch ex2 As MyAppExp2
' Bar
Catch ex3 As MyAppExp3
' Baz
End Try


--
HTH,
-- Tom Spink, Über Geek

Please respond to the newsgroup,
so all can benefit

" System.Reflection Master "

==== Converting to 2002 ====
Remove inline declarations

 

[Tom Spink]

Hi Mike,

Raise Error? Doesn't exist in VB.NET...

--
HTH,
-- Tom Spink, Über Geek

Please respond to the newsgroup,
so all can benefit

" System.Reflection Master "

==== Converting to 2002 ====
Remove inline declarations

 

[Jay B. Harlow [MVP - Outlook]]

Tom,
"Raise Error" didn't really exist in VB6 either. ;-)

You need to use Err.Raise which is supported in both.

Remember in VB.NET Err is in the Microsoft.VisualBasic.Information Module.

I prefer & recommend using Exceptions over Err.Raise. I only have Err.Raise
in code upgraded from VB6, even then I will Refactor
(http://www.refactoring.com) the code to replace Err.Raise with Exception as
time & code permits...

Hope this helps
Jay

 

[Mike]

Sorry I meant throw exception
example at http://www.vbdotnetheaven.com/Code/Jun2003/2009.asp

 

[Rob Teixeira [MVP]]

In reality, it would be more like this (remember, most specific to most
general) -

Catch ex As MyAppExp1
' handle custom exception here
Catch ex As MyAppExp2
' handle other custom exception here
Catch ex As ApplicationException
' handle all other unexpected non-fatal application-specific exceptions
Catch ex As Exception
' handle unexpected base/core exceptions
End Try

Also, don't forget that VB.NET allows user-filtered catch statements (odd
that C# doesn't... yet)

Catch ex As ApplicationException When <Something = Something>
Catch ex As ApplicationException When <Something = SomethingElse>

-Rob Teixeira [MVP]

 

[Tom Spink]

I didn't say it did.....

--
HTH,
-- Tom Spink, Über Geek

Please respond to the newsgroup,
so all can benefit

" System.Reflection Master "

==== Converting to 2002 ====
Remove inline declarations

 

[Jay B. Harlow [MVP - Outlook]]

Tom,

I didn't say it did.....

I'm sorry, obviously someone missed something that someone stated! ;-)

The point of my post was that your statement:

Is false! In VB.NET you use Err.Raise to "Raise Error" just as you do in
VB6.

Hope this helps
Jay