Partnership

Exception handling guidelines Basic ex. handling patterns Guidelines and best practices Anti-patterns, or not ?! Exception handling application block

Introduction Why should we think about the exception handling and the logging? Software maintenance (Administrators, technical support) Uniform and clean code Prevents application of having large amount of unexpected and confusing behavior

Exception handling patterns Exception shielding Protects sensitive information and prevents their leaking Exception translating Wraps original exception with purpose to add some extra info, or to adapt exception to the layer above. Example: Used by Hibernate API (doesn’t throw the SQLException, hides sensitive information) Exception logging Leaves useful information about the exception which occurred

The typical exception handling actions Handle it (perform retry or an additional action) Propagate it (re-throw it) Wrap it and throw a new exception Log it (Do not use Console.WriteLine or System.out to log the data) Mix of previously mentioned approaches

1. Make ex. handling plan in development phase Define exception handling policy for the software architecture: Consider and divide critical parts of the architecture from non critical Put security barriers in the architecture Cover all application threads with safety nets

2. Avoid leaving an empty exception handler Can hide crucial parts of scenario which caused issue Problem diagnosis can be extremely hard (sometimes only debug procedure through tool is only option)

3. Provide as much as possible of exception data Exception message Exception stack trace Exception code (if available) Custom (additional) properties All inner exceptions

4. Take security into consideration Hide sensitive details and information: Database type or provider Server info

5. Put a human readable message in the exception log Helps technical support and administrators. Makes the log file more readable and understandable. Sometimes, raw exception message can be very confusing without some vital information for debug process.

6. Use built-in exceptions if applicable Before you create a new exception class, check whether some system exception can be used. ArgumentException ArgumentNullException InvalidCastException InvalidOperationException System.IO.FileNotFoundException System.IO.PathTooLongException Etc..

7. Create new exceptions by following a platform guidelines All recommended constructors should be supported Make an exception serializable(if necessary) Follow naming convention for the exception class If you chose to override built-in exception follow the same guidelines

8. Avoid resetting stack trace Do not use ‘throw ex;’ to propagate further exception, use ‘throw;’ instead. ‘throw ex’ statement resets stack trace to the point of the current line execution, therefore original exception source is hidden.

9. Study the exception handling policy of the API you use It’s essential to build exception handling logic above it. It’s possible that you will find unexpected behavior which requires special treatment. WCF client dispose method throws additional exception when connection is in the fault state, hiding the real exception cause that way.

10. Handle a specific exception close to the place of its cause All relevant variables and resources are available, therefore the most appropriate ex. handling action can be invoked, either to sanitize exception, retry an action or simply log error data. Human readable (useful) log message can be made with all necessary data. Avoid using general exception handlers for handling specific errors.

Anti-patterns, or not ? Approach log and throw ?! Handler catch (Exception ex) ?! – fine for safety net, wrong for handling specific exceptions Catch and return null – definitely a bad practice (can introduce lots of confusion) Throw from finally – hides real exception (similar to the WCF client dispose issue) Return default value for unimplemented operations in the interface - throw NotImplementedException instead Singleton implementation by the static constructor ?! Ensuring a synchronous approach to the singleton by using a queue execution

Enterprise library - EHAB The Microsoft Enterprise library is a collection of reusable software components called: application blocks, designed to assist developers with common enterprise development concerns (MSDN). Exception handling Application block (EHAB) is designed to centralize exception handling code, make it configurable and helps us to design uniform and easy to change exception handling infrastructure.

EHAB– Main Concepts ExceptionManager – Main entry point for the exception handling functionality. ExceptionPolicyDefinition – Encapsulates one set of rules for handling exceptions. ExceptionPolicyEntry – Defines rule how to handle one specific exception type. IExceptionHandler – Defines contract (interface) for an ExceptionHandler. An ExceptionHandler contains specific handling logic.

EHAB - Initialization Define an exception policy by specifying appropriate policy definitions and supply it to the exception manager. Post handling actions: None – Nothing is propagated further when all exception handlers in the policy chain are done NotifyRethrow – Original exception is propagated further when all exception handlers in the policy chain are done ThrowNewException – Throws new exception, returned by the last exception handler in the chain, to upper level when all exception handlers in the policy chain are done

EHAB – default handlers WrapHandler - Wraps the current exception with a new exception of a specified type. ReplaceHandler - Replaces the exception with an entirely new exception. LoggingExceptionHandler -  formats the exception into a log message and writes it down in appropriate location.

EHAB - Usage Use either Process or HandleException method of the ExceptionManager class. Process method is used to entirely replace try – catch block but it can be used in combination with it. HandleException method is used always in combination with try – catch block and it’s called to handle a specific exception by specified policy (Gives directly a result of the exception handling policy). Use HandlingInstanceId to give a single piece of information to the user which can be used to obtain specific details of exception

EHAB - DEMO In demo simple user management application will be used. Contains DAL (data access layer) layer Has simple UI interface Has exception policy defined in the ApplicationManager singleton

References http://www.vegaitsourcing.rs/#!/articles/2014/1 0/exception-handling http://www.codeproject.com/Articles/9538/Exce ption-Handling-Best-Practices-in-NET http://msdn.microsoft.com/en- us/library/dn440728(v=pandp.60).aspx https://today.java.net/article/2006/04/04/excep tion-handling-antipatterns

Conclusion Always think of the exception handling and logging in design time Follow best practice for the exception handling and try to avoid anti-patterns Use the EHAB or any similar application block to have the exception handling logic centralized, uniform and easy to maintain/change

Thank you