Three Rules for Effective Exception Handling
Well here\'s a list of some more specific techniques on how to manage your exception handling mess:
1. Declare Unchecked Exceptions in the Throws Clause - Make it easy for programmers and the IDE to disc
Tutorial Details:
7. Build Default and Provide For Custom Error Handlers - Many times it is necessary for a client class that doesn\'t directly call another class to affect exception handling at the point of failure. Many frameworks provide handlers that can be attached to classes (for example JCIFS) that permit either default or custom overriding of exception handling logic. Therefore, replace hard coded catch blocks with delegation
try{...}
catch(IOException ex){
Category.getInstance(\"data.jdbc.provider\").error(\"sorry\",ex);
}
--->
try{...}
catch(IOException ex){
handler.handle(\"sorry\",ex);
}
Some words of wisdom from the Spring framework:
The org.springframework.jdbc.core package, uses callbacks to move control - and hence error handling and connection acquisition and release - from application code inside the framework. Spring uses a similar callback approach to address several other APIs that involve special steps to acquire and cleanup resources, such as JDO (acquiring and relinquishing a PersistenceManager), transaction management (using JTA) and JNDI.
Also, as an additional service to your clients, provide some reasonably good default exception handling logic.
8. Declarative Exception Handling - Dynamically change exception handling policy. Handling exceptions is an extremely dynamic concern, provide a flexible framework to manage this. For example Struts allows user defined ExceptionHandlers to be associated on a local or global scope using configuration instead of code. In otherwords, responses to exceptions should not only based on type but also on context in where they are called.
9. Avoid Violating Liskov\'s Principles - Support polymorphic behavior also in your exception handling code. The most straight forwared way is to catch and wrap all exception that expose implementation details. For example:
Why does the Vector class throw an ArrayIndexOutOfBoundsException when all other List interface implementors throw IndexOutOfBoundsException? Doesn\'t this somewhat defeat the purpose of encapsulation, since by throwing ArrayIndexOutOfBoundsException, the Vector class is exposing it\'s internal implementation?? The ArrayList is also based on an array data structure....but it doesn\'t hint it by throwing the more specific exception. Why can\'t they deprecate the method and throw the correct exception?
public void boo( ) throws SQLException ,
JMSException , NamingExcetion
{
...
}//em
-->
public void boo( ) throws DAOException
try/catch & re-throw (wrapped) Exception
}//em
Encapsulate low level throws list with wrapped Execption
10. Ensure Multiple Tier Information Propagation Unless a full recovery can be made - an Exceptions needs to propagate to the presentation tier. Also ensure that Exceptions are serializable so that they can be made available across multiple tiers. Furthermore, if an Exception class cannot be made available across all tiers, wrap that exception class with one that can and preserve the original\'s stack trace.
11. Support Consistent User Communication - Name, Number, Importance, Response, Message should be consistent. Exceptions should also record information that is useful for addressing the problem as well as information that is useful for advising the debugger or the human user. Internationalization should also be supported. Also try to spend more time on useful error messages that show people why the error occurred and give a clue as to how to fix it.
12. Use Command Patterns for Complex Error Handling Logic - Continuations or commands with retry strategies can be used (or service combinators) to create robust ways of handling expected errors. William Grosso explores the Command Pattern wrt to Exceptions in more detail here. The use of Command Patterns allow for more reuseable exception handling logic. For example, you can build a libary of service combinators to support the following:
(1) Sequential s ? t
(2) Concurrent s | t
(3) Timeout t , s
(4) Retry (s)
(5) Non-termination stall
13. Logically Asychronous Calls Should Not Throw Exceptions - Provide support where the failure of an asychronous call may be programatically retrieved using a \"asychrnonous token\". (see Correction Loop)
The Observer shouldn\'t throw exceptions. There is no-one to catch them. The protocol could catch and ignore them, but that\'s dangerous. The Observable doesn\'t know anything about the Observers - that\'s the point of the pattern - so is not interested in their failure.
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Three
Rules for Effective Exception Handling
View Tutorial: Three
Rules for Effective Exception Handling
Related
Tutorials:
 Designing with
exceptions - JavaWorld - July 1998
Designing with
exceptions - JavaWorld - July 1998
|
Building a bigger sandbox -
JavaWorld -
August 1998
Building a bigger sandbox -
JavaWorld -
August 1998
|
Java Tip 39: The trick
to using a basic
Java 1.1 network
and file class
loader - JavaWorld -
Java Tip 39: The trick
to using a basic
Java 1.1 network
and file class
loader - JavaWorld - October
1997
|
The Volano Report: Which Java platform is fastest,
most scalable?
A JavaWorld exclusive! - JavaWorld - Mar
The Volano Report: Which Java platform is fastest,
most scalable?
A JavaWorld exclusive! - JavaWorld - March 1999
|
What's new in Java Servlet API 2.2? -
JavaWorld
October 1999
What's new in Java Servlet API 2.2? -
JavaWorld
October 1999
|
Agents talking to
agents - JavaWorld September
1998
Agents talking to
agents - JavaWorld September
1998
|
One, two, three,
or n tiers? - JavaWorld January 2000
One, two, three,
or n tiers? - JavaWorld January 2000
|
Building a Java servlet framework
using reflection, Part 2 - JavaWorld February 2000
Building a Java servlet framework
using reflection, Part 2 - JavaWorld February 2000
|
Frameworks save the
day - JavaWorld September 2000
Frameworks save the
day - JavaWorld September 2000
|
Validation with Java and XML schema, Part 1 - JavaWorld September 2000
Validation with Java and XML schema, Part 1 - JavaWorld September 2000
|
Validation with Java and XML schema, Part 4 - JavaWorld December 2000
Validation with Java and XML schema, Part 4 - JavaWorld December 2000
|
Optimistic
Locking pattern for EJBs - JavaWorld July
2001
Optimistic
Locking pattern for EJBs - JavaWorld July
2001
|
J2SE 1.4
premieres Java's
assertion capabilities, Part 2
J2SE 1.4
premieres Java's
assertion capabilities, Part 2
|
Use Web services
to integrate Web applications with
EISs
Use Web services
to integrate Web applications with
EISs
|
Test networked
code the easy way
Test networked
code the easy way
|
Business process
automation
made easy with
Java, Part 1
Business process
automation
made easy with
Java, Part 1
|
Business process
automation
made easy with
Java, Part 2
Business process
automation
made easy with
Java, Part 2
|
Nested Classes, Part 1
Nested Classes, Part 1
The concept of nesting a class within another class or method presents unique issues not found elsewhere in object-oriented programming.
|
Aspect-Oriented Programming in Java
This article is divided into three parts: The first part explaines the concepts of AOP, the second introduces AspectJ(TM), an implementation of the AOP concepts in Java, and part three compares the AOP approach to metalevel programming.
|
Euler proof mechanism
Euler is an inference engine supporting logic based proofs of test cases (*).
|
|
|
|
