Exceptions are a construct in the .NET Framework that are (ideally) used to indicate an unexpected state in executing code. For example, when working with a database
the underlying ADO.NET code that communicates with the database raises an exception if the database is offline or if the database reports an error when executing a query.
Similarly, if you attempt to cast user input from one type to another - say from a string to an integer - but the user's input is not valid, an exception will be thrown.
You can also raise exceptions from your own code by using the Throw keyword.
When an exception is thrown it is passed up the call stack. That is, if MethodA calls MethodB, and
then MethodB raises an exception, MethodA is given the opportunity to execute code in response to the exception. Specifically, MethodA can
do one of two things: it can catch the exception (using a Try ... Catch block) and execute code in
response to the exception being throw; or it can ignore the exception and let it percolate up the call stack. If the exception is percolated up the call stack - either by
MethodA not catching the exception or by MethodA re-throwing the exception - then the exception information will be passed up to the method that
called MethodA. If no method in the call stack handles the exception then it will eventually reach the ASP.NET runtime, which will display the configured error
page (the Yellow Screen of Death, by default).
In my experience as a consultant and trainer I have worked with dozens of companies and hundreds of developers and have seen a variety of techniques used for handling
exceptions in ASP.NET applications. Some have never used Try ... Catch blocks; others surrounded the code in every method with one. Some logged exception
details while others simply swallowed them. This article presents my views and advice on how best to handle exceptions in an ASP.NET application. Read on to learn more!
Read More >