Updated with links of Other Application Blocks
Introduction
Exception handling is one of the most important tasks in any application. Many applications either do not handle applications or they handle it in an adhoc manner. In this section we will see how we can use the readymade exception handling block so that we do not need to code and build error handling routines from scratch.
Other Application Blocks
Validation application blocks: - This article explains the 16 steps you need to perform to do validations using VAB.Validation application blocks
Client side validation: - One of the short comings in VAB is that it does only server side validations. This article talks how we can leverage VAB for client side.Client side validation
Dynamic validation: - This article explains how to build dynamic validation on scenario basis.Dynamic validation
Policy Application blocks: - This article talks how to implement plug and play mechanism using Policy application blocks.Policy application block
Logging application block: - This article explains the 5 basic steps of how to use logging application blocks.
Logging application block
Data application: - This article talks about the four steps you need to implement data application blocks.
Data application block
Unity application block: - This application talks about Unity Application Block in DI and IOC.Unity application block
UIP block: - This article talks about Reusable Navigation and workflow for both Windows and Web using Microsoft UIP blocks.UIP block
Problem
A good error handling has the following features:
- You would like to log errors in a source like event viewer, file etc for further debugging and inspection.
- You would also like to change these error logging sources on fly without compiling the project. So sometimes you like to see the error logged in event viewer and sometimes you would like to send an email for some critical errors to the administrators.
- You would also like to apply different error policies depending on where the error occurs. For instance if the error occurs on the UI you would like to throw the error on a label and if it happens on the data access layer you would like to log the error. For some errors you would like to replace it with some custom exception.
- Finally you would like to add, update and remove these error policies depending on situations on fly without compiling the code.
So what is the problem? If we want to build the above features from scratch it’s a project by itself.
The Solution
The answer to the above problem is use the readymade block exception handling block.
Step 1:- The first thing we need to do is add the logging application block. In case you have not read about logging application block please read about it at Questpond1.aspx. As we had mentioned previously one of the important aspects in error handling is that we should be able to log the errors in some source. This capability is provided by logging application blocks.
Step 2:- Now that we have defined where the errors should be logged it’s time to define exception policies. So right click and add exception handling application block and then right on the exception handling block to add exception policies as shown in below figure.
We will give a name to this policy as ‘Policy1’.
Step 3:- Now right click on policy 1 and define a new exception type as shown in below figure.
For the current scenario select the exception type as general .NET exception as shown in below figure. This type specifies that the policy will catch this type of exception.
Step 4 :- In case this exception occurs we would need to direct the exception block what should be done. For policy exception we would like to log the same in the logger. So click on the exception defined in policy 1 and say that this needs to be logged using the logging handler.
Specify the logging source for the logging handler as shown in below figure:
Select the formatter type as shown in below figure:
Step 5:- Let’s make this example more interesting to exploit the real essence of exception handling block. Let’s add one more policy called as policy 2. In policy 2 we will catch the arithmetic exception. This arithmetic exception will be replaced by general exception.
To define general exception right click on arithmetic exception and define the replace exception type as exception.
Below figure shows how we have define the replace exception type as general exception and a new exception message.
So we have defined two policy one policy i.e. policy1 will take the exception and log it in the event viewer and the other policy will take a arithmetic exception and replace it with a general exception and throw it to the caller.
Step 6:- Now the final step calling the exception policy in the code. So first import the namespace i.e. exceptionhandling and logging in code.
Finally use the exceptionpolicy static class to handle the exception. You can see in the below figure we have two button one which uses policy1 and the other policy2.
The output of policy1 will be logged in to event viewer as shown in below figure.
The output of policy2 will be replaced with a general error as shown in below figure.
The best part of exception handling block is you can change policy on fly without compiling the code. You can also change the error logging source from event viewer to file or email. I hope you have enjoyed this article and I am sure if you use this block properly you can have a very stable, efficient and flexible error handling framework.
For further reading do watch the below interview preparation videos and step by step video series.
