Insight from Agora Consultants

Exceptions Happen - Deal With It!

In my last post (Mosquito Coils and Software Design) I discussed how defensive design can be used to ensure a product can still be used even after a failure of one part of the system.  Defensive design can be divided into many different areas.  Clearly one of the areas to concentrate on is security measures.  Attacks such as code injection and cross-site scripting are common security vulnerabilities that can be mitigated using good design.  Defensive design should also include the eventuality of failure.  It is important to have high quality processes for developing good code, but you must also consider what happens when thing go wrong. Exceptions will happen – deal with them! All applications will encounter exceptions at some point in their life.  Exception management should be a fundamental part of your application design.  Your design should, at minimum, consist of a code and process to handle: Exception Throwing – Exception are “thrown” when a chunk of code cannot do what it was designed to do.  See the MSDN article ( for some excellent best practices on throwing exceptions. Exception Handling – Once your application throws an exception you need to handle it.  There are really only three things you can decide to do: (a) Burying the exception.  This is the least desirable (even unacceptable) since the user or the developer will never know about the exception except the user may complain the application is not working correctly; (b) Notify the user about the exception.  This is typically done with a dialog box and some additional information to let them know that things did not go as planned; (c) Notify the user and log the exception.  This is the best option since the user knows that something happened and the QA and development team can analyze the exception.  See for best practices on handling exceptions. Issue Management – Once the exception has been logged the team needs to determine what do about it.  Is it an operations issue or a code issue?  Does it need to be fixed?  If so, when should it be fixed and by whom?  Tracking an exception through its eventual final disposition is a critical part of Application Lifecycle Management. Agora Exception Tracker One of the most exciting components of the Agora Development Framework is Exception Tracker.  The Exception Tracker was written as an extension to the Microsoft Exception Management Block.  Now a standard component in every application we write, the Agora Exception Tracker has the capability of publishing exceptions from an application to a web service, the Windows Event Log, a text file, or as email.   Other Considerations Other key things to consider in your design to enable you to have a more robust application include: Performance counters - Make use of the perfomance counter capabilities within Windows the track the health of your application. Configuration files or Database settings - Place as much of the configuration options into configuration files or into the database.  Allowing the administrator to tweak and configure your applications at runtime can eliminate a whole class of issues. Abstract language and regional settings from the application - Keeping all languate and regional settings out of your application and in resource files or the database will pay huge dividends.  Not only does this allow you to reach a broder audience quickly, you will also get the advantage of being able to make changes to the application at runtime.  (See Garry English's article on editing resource files -