Best practices for exception handling within .NET

While understanding the best practices for exception handling / tracking / etc., in the .NET, I’ve ended up with the below information

Best practices in Exception handling within .NET

Before identifying the best practices, it is mandatory to identify the exception generation situations and handle them to the best need of the situation. The below is the best scenario for the exception handling.

 Fig 1: Exception Workflow

[Source : Internet, I forgot the source link, but I’ve copied this above diagram. As soon I find the source, would mention here. In case if the reader came across of the previous article, please let me know

The above diagram is copied from Christian Thilmany’s blog post from this link.]

There are two ways of handling these exceptions

·         Catch them & Act Immediately

o   Early

o   Late

·         Catch them to Record (or) log & Act afterwards

Catch & Act

This mechanism is generally implemented in all the coding practices. This approach is implemented by the “try .. catch .. finally” key block. This is the finest mechanism provided by the .NET framework. Yet, this is very expensive to use and implement. The “try .. catch .. finally ..” causes an extra amount of memory management code. Thus, .NET framework provides a flexibility of custom exception classes implementation to handle them within the application. Hence we have the below 2 options

·         Usage of inbuilt TRY CATCH FINALLY is a SEH, ie., Structured Exception Handling mechanism

·         Implement custom EXCEPTION classes

Conclusion & Recommendation

Use the “TRY..CATCH..FINALLY” to catch the exception early and customize the exceptions into generic classes. Implement the needed functionality on the custom classes. Thus, I recommend to implement

1.       the “TRY..CATCH..FINALLY” block in all the unknown scenarios

2.       Implement a custom exception class for all the known exceptions

3.       Implement “TRY..CATCH..FINALLY” block only at the data layer

Record & Act

This mechanism is generally implemented in all the portals where the exceptions are not handled immediately thru coding, but for recording and the purpose of investigation. In this mechanism, all the exceptions are consumed by the code and recorded. These exceptions are not exposed to the end users. A generic message (or) a generic page is navigated when any source throws exception. Hence, the end user is not aware of the original exception message, which is recorded for future purpose.

Over periodic intervals these recorded exception messages are investigated and traced the root cause. There are various implementation practices for this kind of coding practice. One of the best mechanism is to have these exceptions caught and recorded at

·         Application level

·         Session level

·         Request level

All these exceptions which are caught at various levels are recorded at various means. The commonly used practice is to write them to event log under a specific EVENT log. It is not a WISE practice to write to generic event log.

There is various reusable exception handling frameworks that are available in the current world. The below are the few names that are popularly used.

·         EHAB : Enterprise Library Exceptional Handling Application Block

·         Log4net : Widely used by industry  in the previous years

·         ELMAH : Acquiring the industry adaption as the new versions are finding this as friendly

The best practice of these recordings done by these tools is to a variety of locations like the below mentioned

·         The event log

·         An e-Mail message

·         To Database

·         A Message Queue

·         A Text file

·         WMI Event

·         Custom format and locations. XML formats, encrypted formats, etc .,are stored at network drives

 

Conclusion & Recommendation

Use the “TRY..CATCH..FINALLY” to catch the exception early and customize the exceptions into generic classes. Implement the needed functionality on the custom classes. Thus, I recommend to implement

1.       The “TRY..CATCH..FINALLY” block ONLY in all the unknown scenarios

2.       Implement a custom exception class for all the known exceptions

3.       Implement “TRY..CATCH..FINALLY” block ONLY at the data layer

NOTE: I highly recommend to the implementation of ELMAH. But we need to have a process in place to investigate and deal the exception.

On top of all, in the bottom line of my heart, I’m an ardent believer of “not using the TRY CATCH block”. Thus, most of my code is written without TRYCATCHes. I’ve been successful all these days. Need to learn where would I fail so that I start use the TRYCATCHes