Advertisement

Conclusion
The most important point to take away from this article is that exceptions are there for abnormal conditions and shouldn't be used to report conditions that can be reasonably expected as part of the everyday functioning of a method. Although the use of exceptions can help make your code easier to read by separating the "normal" code from the error handling code, their inappropriate use can make your code harder to read.

Here is a collection of the exception guidelines put forth by this article:

• If your method encounters an abnormal condition that it can't handle, it should throw an exception.

• Avoid using exceptions to indicate conditions that can reasonably be expected as part of the normal functioning of the method.

• If your method discovers that the client has breached its contractual obligations (for example, by passing in bad input data), throw an unchecked exception.

• If your method is unable to fulfill its contract, throw either a checked or unchecked exception.

• If you are throwing an exception for an abnormal condition that you feel client programmers should consciously decide how to handle, throw a checked exception.

• Define or choose an already existing exception class for each kind of abnormal condition that may cause your method to throw an exception.

Next month
In next month's Design Techniques I'll continue the mini-series of articles focusing on class and object design. Next month's article, the sixth of this mini-series, will discuss design guidelines that pertain to thread safety.

A request for reader participation
I encourage your comments, criticisms, suggestions, flames -- all kinds of feedback -- about the material presented in this column. If you disagree with something, or have something to add, please let me know.

You can either participate in a discussion forum devoted to this material or e-mail me directly at bv@artima.com.

Resources

• Recommended books on Java Design
  http://www.artima.com/designtechniques/booklist.html
• Source packet that contains the example code used in this article
  http://www.artima.com/flexiblejava/exceptions.html
• The discussion forum devoted to the material presented in this article
  http://www.artima.com/flexiblejava/fjf/exceptions/index.html
• Object Orientation FAQ
  http://www.cyberdyne-object-sys.com/oofaq/
• 7237 Links on Object Orientation
  http://www.rhein-neckar.de/~cetus/software.html
• The Object-Oriented Page
  http://www.well.com/user/ritchie/oo.html
• Collection of information on OO approach
  http://arkhp1.kek.jp:80/managers/computing/activities/OO_CollectInfor/OO_CollectInfo.html
• Design Patterns Home Page
  http://hillside.net/patterns/patterns.html
• A Comparison of OOA and OOD Methods
  http://www.iconcomp.com/papers/comp/comp_1.html
• Object-Oriented Analysis and Design Methods: A Comparative Review
  http://wwwis.cs.utwente.nl:8080/dmrg/OODOC/oodoc/oo.html
• Patterns discussion FAQ
  http://gee.cs.oswego.edu/dl/pd-FAQ/pd-FAQ.html
• Implementing Basic Design Patterns in Java (Doug Lea)
  http://g.oswego.edu/dl/pats/ifc.html
• Patterns in Java AWT
  http://mordor.cs.hut.fi/tik-76.278/group6/awtpat.html
• Software Technology's Design Patterns Page
  http://www.sw-technologies.com/dpattern/

About the author
Bill Venners has been writing software professionally for 12 years. Based in Silicon Valley, he provides software consulting and training services under the name Artima Software Company. Over the years he has developed software for the consumer electronics, education, semiconductor, and life insurance industries. He has programmed in many languages on many platforms: assembly language on various microprocessors, C on Unix, C++ on Windows, Java on the Web. He is author of the book: Inside the Java Virtual Machine, published by McGraw-Hill. Reach Bill at bv@artima.com.

This article was first published under the name Designing with Exceptions in JavaWorld, a division of Web Publishing, Inc., June 1998.