Exception Handling in C#
It is very common for software applications to get errors and exceptions when executing code. If these errors are not handled properly, the application may crash and you may not know the root cause of the problem. Exception handling is the method of catching and recording these errors in code so you can fix them. Usually, errors and exceptions are stored in log files or databases.
In C#, the exception handling method is implemented using the try-catch and finally statement. In this article, learn how to implement exception handling in C#.
Try, catch, and finally in C#
The try, catch, and finally statement in C# implements exception handling. The try encloses the code that might throw an exception, whereas the catch handles an exception if one exists. The final is used for any cleanup work that needs to be done.
Try catch finally block syntax.
If any exception occurs inside the try block, the control transfers to the appropriate catch block and later to the final block.
But in C#, both catch and finally blocks are optional. The try block can exist either with one or more catch blocks or a final block or with both catch and finally blocks.
If there is no exception occurring inside the try block, the control directly transfers to the final block. We can say that the statements inside the final block are always executed. Note that it is an error to transfer control out of a final block by using break, continue, return, or goto.
Here is a detailed article on C# Try Catch Statement.
Uncaught Exceptions in C#
Let's learn this by example. The following program will compile but will show an error during execution. The division by zero is a runtime anomaly, and the program terminates with an error message. Any uncaught exceptions in the current context propagate to a higher context and look for an appropriate catch block to handle it. If it can't find suitable catch blocks, the default mechanism of the .NET runtime will terminate the execution of the entire program.
The modified form of the above program with an exception-handling mechanism is as follows. Here we are using the object of the standard exception class DivideByZeroException to handle the exception caused by division by zero.
The result from the above code is shown below.
In the above case, the program does not terminate unexpectedly. Instead, the program control passes from where the exception occurred inside the try block to the catch blocks. If it finds any suitable catch block, it executes the statements inside that catch and continues with the normal execution of the program statements.
If a final block is present, the code inside the final block will also be executed.
Remember that in C#, the catch block is optional. The following program is perfectly legal in C#.
In C#, a try block must be followed by either a catch or a final block. But in this case, since there is no exception handling catch block, the execution will get terminated. But before the termination of the program, statements inside the final block will get executed.
Multiple Catch Blocks
A try block can throw multiple exceptions, which can be handled using multiple catch blocks. Remember that a more specialized catch block should come before a generalized one. Otherwise, the compiler will show a compilation error.
Catching all Exceptions in C#
By providing a catch block without brackets or arguments, we can catch all exceptions that occurred inside a try block. Even we can use a catch block with an Exception type parameter to catch all exceptions that happen inside the try block since, in C#, all exceptions are directly or indirectly inherited from the Exception class.
The following program handles all exceptions with an Exception object.
Throwing an Exception in C#
In C#, it is possible to throw an exception programmatically. The 'throw' keyword is used for this purpose. The general form of throwing an exception is as follows.
For example, the following statement throws an argument exception explicitly.
Re-throwing an Exception in C#
The exceptions we caught inside a catch block can be re-throwing to a higher context by using the keyword throw inside the catch block. The following program shows how to do this.
Standard Exceptions in C#
There are two types of exceptions: exceptions generated by an executing program and exceptions generated by the common language runtime. System. The exception is the base class for all exceptions in C#. Several exception classes inherit from this class, including ApplicationException and SystemException. These two classes form the basis for most other runtime exceptions. Other exceptions derive directly from the System. Exception includes IOException, WebException, etc.
The common language runtime throws SystemException. The ApplicationException is thrown by a user program rather than the runtime. The SystemException includes the ExecutionEngineException, StaclOverFlowException, etc. We are not recommended to catch SystemExceptions, nor is it good programming practice to throw SystemExceptions in our applications.
- System.OutOfMemoryException
- System.NullReferenceException
- System.InvalidCastException
- System.ArrayTypeMismatchException
- System.IndexOutOfRangeException
- System.ArithmeticException
- System.DevideByZeroException
- System.OverFlowException
User-defined Exceptions in C#
In C#, it is possible to create our exception class. But Exception must be the ultimate base class for all exceptions in C#. So the user-defined exception classes must inherit from either the Exception class or one of its standard-derived classes.
Design Guidelines in C#
Exceptions should be used to communicate exceptional conditions. Please don't use them to communicate expected events, such as reaching the end of a file if there's a good predefined exception in the System namespace that describes the exception condition one that will make sense to the users of the class-use that one rather than defining a new exception class and putting specific information in the message. Finally, if the code catches an exception that it isn't going to handle, consider whether it should wrap that exception with additional information before re-throwing it.