Sunday, January 24, 2010

Exceptions Designing in Applications



Exceptions
Exceptions are used to tell the user of System/API that something wrong/unexpected is happened during the execution.So the points to be considered while designing the exceptions are:
  • Message should be clear and meaningful to the user
    • Exception should help the user to understand that what might have happened during the execution.
    • Low level system internal exceptions should be wrapped in business or user specific exceptions.
    • Exception should help user to decide the next steps of operation, so exception should carry the required information like error code, message or reason of the error.
  • Message should not be overloaded
    • Only that information should be given which is relevant to the user. 
    • Extra information may confuse the user without much use. So internal exceptions or stack traces should not be passed to the user.
  •  Message should be as per user expectations
    • Possible exceptions should be defined using 'Checked Exceptions'.
    • There should be no surprise for user, i.e. unchecked exception should not be passed to user generally (runtime exceptions allowed only if system can not sustain with this exception)

Design for Exception Objects
A few information which exception object should carry

  • Exception Name 
    • Name should reveal the reason of exception
    • Example: 'FileNotFoundException' shows that some expected file is missing from its path
  • Exception Message
    • Message should be clear enough to give required information to user.
  • Wrapped Exception
    • Any internal exception can ride the main exception as extra information
  • Error Code
    • Error code can be used for getting internationalized message string at UI layer from language resource files.
    • Error code can also be used internally, within a system, to categorize the exception and to take appropriate step based on this category of error. For example, if we get 'ResourceNotFoundExceptoin', then error code 1 can be for 'File resource', 2 can be for 'network connection' and 3 can be for 'configuration file'.
Ideally Exception objects carry data only and does not posses any behavior. However, in some special cases like in a framework design, these can exhibit some behavior also like logging the messages to using Application Logging Framework.

Checked or Unchecked Exception
You will find many debates over this issue on internet. As a thumb rule, unchecked exceptions should be used only if system is unable to sustain after any exception. But some framework designer use unchecked exceptions for passing the exception internally within the framework. They throw unchecked exception and put all exception management code at the outermost layer. But this is a special technique which is used for some specific purpose and in some big systems only. So let us keep a distance from this, and follow the thumb rule.

A few points to consider while designing and using the exceptions
  • Don’t use exceptions for flow control and expected business situations, but only for exceptional situations
  • Use unchecked exceptions for programming errors, bugs, situations where the application or the current operation cannot expect to recover from.
  • Use checked exceptions for situations where the caller is expected to be able to make a full or partial recovery after the failure
Exception Management Framework
Exception Management Frameworks can be designed to serve various purposes like
  • At UI Layer, framework can be used to handle the exception and show the error message to the user in a generic way. Things which can be automated are
    • Logging of Exception
    • Retrieve the internationalize message for exception
    • Load the error page with this message
    • Configure the error page with a back button to come back to the application flow
  • In business Layer
    • Logging of Exception to file or to database
    • Raise alarm, like mail to system admin for exception reporting
Frameworks can be very large based on the application requirement, where they can manage the logging of exceptions and alert management intelligently using some workflow and also show the reports to administrator applying business intelligence. In large system, XML based configurations can be used for specifying the Exception Handlers which can be loaded lazily as per exception situation.

1 comment:

  1. If we are using XML based configuration, it can be like specifying various kind of handlers depending upon error code, or severity etc. Handlers can be like MailSender, and Database Logger etc. So whenever anyone face error, she should simply call framework method to handle the exception. Framework will read the XML, will decide that what all handlers should be invoked to manage these error, and will do that.

    ReplyDelete