Last post Feb 09, 2015 09:41 PM by gerrylowry
Feb 09, 2015 07:19 AM|damon2012|LINK
When you throw an exception, where does it go to?
Do you have to actually write a catch somewhere after you throw it?
Feb 09, 2015 07:37 AM|PatriceSc|LINK
Web forms or MVC? See
The basic idea is to start with a general handler with the default behavior (likely logging errors somewhere so that they can be reported to the dev team and fixed) and then to catch locally if you can do something that makes more sense at a particular place
and for particular exception types.
Feb 09, 2015 07:38 AM|Mikesdotnetting|LINK
It goes up to the calling code (if there is any). Take the
Convert.ToInt32 method. It can generate a FormatException or an OverflowException given certain incorrect inputs. It throws those exceptions to the code that uses the method to let it know what went wrong. It's up to you as the consumer of the method what
you now do with the exception. You can throw it again or write a catch block and handle it. If you are writing an API, you will probably rethrow the exception or throw a custom exception. If you are using the method in a code behind, you might catch the exception
instead and provide a friendly error message to the user, or you might decide to do nothing and let your custom error page display instead.
Feb 09, 2015 07:41 AM|AidyF|LINK
You don't have to catch it yourself, the exception goes up the call stack (so the method that called your code, then the method that called that method and so on) until something catches it. If nothing catches it it becomes an "unhandled" exception and
the user will see an error screen.
Feb 09, 2015 09:41 PM|gerrylowry|LINK
(a) it goes UP because of the way we tend to graph calls and returns visually:
Boot (power on)
operating system (example windows)
some .NET method
call to windows kernel (input-output)
For example, you may throw an exception in your method in the above diagram, on purpose, or an exception might happen because of some bug in your code (divide by zero) ... or at a lower level some exception my happen such as running out of disk space.
(b) you are not obligated to catch your own throws ... you can if you want to. for example:
you have written code than sends an e-mail;
you have an ASP.NET MVC ActionResult that calls your e-mail method to send a confirmation to an end user;
your e-mail method fails and you build a custom exception which you throw, for example, you may include some help information to be passed back to your end user.
in the above example, your e-mail method throws the exception, your ActionResult passes the caught exception message to View for your end user to read.
See also http://forums.asp.net/post/5762202.aspx
damon2012, when you throw exceptions, you should document them ... you will notice that MSDN does that ... users of your code should know what exceptions to expect so that they
can catch them and avoid the embarrassing yellow screen of death.