Rule

Error Example

Explanation

Always pass the original exception

catch (IOException e) {

   throw new RuntimeException("Problem in I/O.");

}

The original problem may be hidden if you do not do this. The original exception can be passed on by adding it to the message:

("message: " + e);

It is better to use a constructor that can take an exception as argument as well, for example:

new PortalRuntimeException("Error in I/O.", e)

Always include a message

throw new IOException();

There is always additional information which is useful to the user. If possible this information should be constructed dynamically. However, this should not introduce problems. The following example produces a NullPointerException if the context is null:

throw new RuntimeException("Error in "+ context.getComponent());

Do not make wrong assumptions

catch (NamingException e) {

throw new PortalRuntimeException("Registry not found:" + e);

}

There are many subclasses of NamingException and the reason may be other

Do not have empty exception handlers

catch (Exception e) {

   // ignore

}

Do not only print the stack trace

catch (NamingException e) {

   e.printStackTrace();

}

If stdout is not redirected, the exception is only visible on the console. The console, however, may not always be there or accessible, for example the application was started using javaw which does not open a console. In addition, there is sometimes too much output on the console thus making it impossible to follow the output. The exception should be logged.

Log important Exception

catch (IOException e) {
   throw new RuntimeException ("Exception while reading service parameters: " + e);
}

In general, when important information is lost in an exception handler because it is not passed on, it should be logged. The following line logs the stack trace of the exception above:

PortalRuntime.getLogger().severe(e, " Exception while reading service parameters.");