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
When an exception is thrown it is passed up the call stack. That is, if
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
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
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!