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)