Archive

Posts Tagged ‘checked exceptions’

Exceptions – Kick start guide to designing exceptions for your system

February 13, 2010 Leave a comment

The main problem with exception handling is knowing when and how to use it. Exception designing requires discretion, experience in OO programing and knowledge of the users of your system.

What is an Exception?
An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program’s instructions. When an error occurs within a method, the method creates an object and hands it off to the run time system. The object, called an exception object, contains information about the error, including its type and the state of the program when the error occurred. Creating an exception object and handing it to the run time system is called throwing an exception.

Types of Exceptions:
There are two types of exceptions:

  1. Checked Exceptions
  2. Unchecked Exceptions

Checked exceptions represent invalid conditions in areas outside the immediate control of the program (invalid user input, database problems, network outages, absent files) Checked exceptions forces the user to use a try-catch block to catch the exception.

To quote from The Java Programming Language, by Gosling, Arnold, and Holmes : “Unchecked run time exceptions represent conditions that, generally speaking, reflect errors in your program’s logic and cannot be reasonably recovered from at run time.” . Unchecked exception doesn’t impose the use of try-catch block and this is caught at the highest level. They are subclasses of RuntimeException, and some examples are IllegalArgumentException, NullPointerException and IllegalStateException.

Checked or Unchecked Exceptions?
There are many arguments for and against both checked and unchecked, and whether to use checked exceptions at all. What I am going to say below is what sounds best to me (and a couple of people around me at Yahoo!).

Why custom defined exceptions?

In the above diagram the user of the system should be aware of exceptions A,B,C which are some custom exceptions of internal components. So, the user has to import A,B,C. It is highly impractical and illogical for the user of the system to be aware of the internal exceptions. So it makes sense to wrap all the internal exceptions in a custom exception Z. The user of the system will have to know about and import only z.

Let us consider that we are building a Banking software. The component built by us will be used by another team. The diagram below adds more clarity to our understanding.

When to use custom unchecked Exception?

Use unchecked exceptions when the user of system can’t recover from the error.

When to use custom checked Exception?

Use checked exceptions when the user of system can recover from the error.

What should be avoided?

One should avoid creating an Exception explosion. Try to limit the number of custom defined exceptions as it would become inconvenient for user of the system.

What can be my next steps?

Look at Decorator pattern to improvise the design.

Advertisements