Throws Statement

R

rbulph

Junior Contributor
Joined
Feb 17, 2003
Messages
397
What does the "Throws" statement do? The VB help file is typically unhelpful saying:

"The Throw statement throws an exception that you can handle with structured exception-handling code (Try...Catch...Finally) or unstructured exception-handling code (On Error GoTo). You can use the Throw statement to trap errors within your code because Visual Basic moves up the call stack until it finds the appropriate exception-handling code."

OK, so I know where the "Throws" statement is used, but there is no explanation as to what throwing an exception is or does. What are the practical consequences of throwing an exception? What does it mean?
 
Exceptions are the .Net way of raising / handling errors.

To handle an exception you would use a Try ... Catch ... Finally block.

If you need to signal your own error conditions then you use the throw keyword to raise a new exception.

e.g.

Visual Basic: 
    Public Sub Test(ByVal name As String)

        If name Is Nothing OrElse name = String.Empty Then  'check name is valid
            Throw New ArgumentException("You must provide a valid name", "name")    'if not raise our exception
        End If

        'more code here
    End Sub
 
Last edited:
Thanks. I note that in the IDE, when you throw an exception, execution stops, the code is shown outlined in yellow and a box is shown with a blue banner and description of the error. But in the release exe, the user is shown a different dialogue box with the option to continue or quit.

Furthermore, when you throw an exception in an override of the ConvertFrom method of the ExpandableObjectConverter (which is what I'm working with for the propertygrid) you get different behaviour. In the IDE you get the same result as described above, but you then get a message in the application stating "Property value is not valid" with the parameter to the exception you have thrown in the dropdown of this message. You get this message in the exe as well. I'm not quite sure what the mechanism is for it to work differently in this method, but it works well, so I can't really complain. However it would be quite good if you could get the release exe style behaviour when debugging so that you can easily see what the user will see.
 
If you are in the IDE you can use CTRL+F5 to run without attaching a debugger.

If you are hitting exceptions in debug mode then that means a release build will crash - you should be dealing with the exceptions in a try ... catch block.
 
What happens when you throw an exception depends on where and when it is thrown. When you throw an exception .Net crawls up the calls stack, looking at each function from the one most recently called up to the first function called, until it finds an exception handler (Try block).

There is always an exception handler somewhere. In debug mode at the top level is the "Exception Assistant". In release in winforms apps it is the "Unhandled Exception" window, and in consoles it simply outputs a message. The debugger can also intercept exceptions for you, which means that you will see the exception assistant even if there is a handler somewhere up the chain. If you don't catch your exceptions they will usually trigger one of the above error handlers.

If there is a .Net function on the call stack (for example, if you call a .Net function which, in turn, calls one of your functions) that .Net function could have an exception handler, which means that it might eat the exception and do nothing, or it could throw a different exception in response.

When you throw an exception it doesn't always reach the top level handler (for example, the "unhandled exception" window in a realease build), and you should never assume it will. In fact, ideally, in a well designed application, it never will. The whole idea behind an exception is that your program can catch the exceptions and react to them without the program grinding to a halt or showing the user some horrific, confusing "unhandled exception" window.
 
Thanks, helpful replies. This is a lot better than VB6 where an unhandled exception would just cause the application to close.
 
Back
Top