Handling Anomalies: Errors and Exceptions
This is the thirty-seventh installment in a series of articles about fundamental object-oriented (O-O) concepts and related object-oriented technologies. The material presented in these articles is based on material from the second edition of my book, The Object-Oriented Thought Process, 2nd edition. The Object-Oriented Thought Process is intended for anyone who needs to understand basic object-oriented concepts and technologies before jumping directly into the code. Click here to start at the beginning of the series.
In keeping with the code examples used in the previous articles, Java will be the language used to implement the concepts in code. One of the reasons that I like to use Java is because you can download the Java compiler for personal use at the Sun Microsystems Web site http://java.sun.com/. You can download the standard edition, J2SE 5.0, at http://java.sun.com/j2se/1.5.0/download.jsp to compile and execute these applications. I often reference the Java J2SE 5.0 API documentation and I recommend that you explore the Java API further. Code listings are provided for all examples in this article as well as figures and output (when appropriate). See the first article in this series for detailed descriptions for compiling and running all the code examples (http://www.developer.com/design/article.php/3304881).
For the past several months, you have been exploring various issues regarding object integrity, security, and performance. In this month's article, you review a concept that I touched on briefly earlier in the series error handling. In this article, you will cover the basic concepts of error handling with the intent of delving much deeper into this topic in future articles.
The Meaning of a Word?
It is important to realize that this article's focus is on error handling and not specifically on exceptions. Although exceptions are the true objects (as with all objects, the Exception class inherits from the Object class), Exceptions are not the only technique for error handling. In fact, the terminology can get a bit tricky. Technically, errors and exceptions are defined as two totally separate entities in the Java programming specification. Both errors and exceptions inherit from a class called Throwable, as seen in Diagram 1.
Diagram 1: The Throwable inheritance tree.
Although you often hear the terms 'catching an exception' or 'handling an error' used quite often, you don't often hear the term 'Throwable' used in many places (although you may well hear someone refer to throwing an exception).
This is why the terminology may get a bit confusing when discussing error handling. Error handling has always been a major part of programming; however, throwing and catching Exceptions are somewhat newer concepts. In any case, what exactly does Throwable mean and how does it relate to Errors and Exceptions?
What Is Throwable?
The definition from the Java API specifications describes the Throwable class as follows:
In my experience, the best way to distinguish between an Error and an Exception is this: An error tends to be an anomaly that is so serious that the application can't continue. This may be something such as a hardware failure or a memory issue that corrupts the execution of an application. In general, it may not be the best idea to catch an Error; in fact, it well might be impossible. When encountering an Error, as you may have surmised, the application will terminate abnormally (in other words, a crash). The Java API describes the Error class in this way:
The Exception, on the other hand, exists to assist in the flow of an application. Exceptions occur in situations where the operating system identifies an anomaly, yet the application is capable of 'catching' the anomaly—and then presumably handling it appropriately. The definition for the Exception class is as follows:
You will explore the important differences between Errors and Exceptions in a later article. However, with this brief description of the Throwable class hierarchy, let me explain the general concept of error handling by using the term anomaly so that you can be inclusive of Errors and Exceptions without the confusion.
Page 1 of 5