This problem actually shows one difficulty in designing for object-oriented programming. For us “intelligent” human beings, it seems just so natural that we have ArithmeticException as a subclass of RuntimeException, because an arithmetic exception occurs during runtime.Contrary to what many of us have been taught, inheritance in OOP isn’t really an “is a” relationship. If you have a Penguin class that only swims, you can’t have it as a subclass of the Bird class that can only fly. Inheritance in OOP is achieved, when the subclasses have the same functions and variables as the superclass (and maybe more). In other words, a subclass needs to behave like the superclass (maybe in an abstract way).

Now, what is behavior for an exception class? The only function really intended to be overridden by subclasses is the getLocalizedMessage(), but I’m going to debunk this function later on. The subclasses don’t really have any useful behavior. They might as well all be immediate subclasses of Exception (or Throwable). Or, what’s more, they might as well be just one class with an enum attribute to determine the type. Then, we wouldn’t need so many catch clauses for exception handling, and conversion of exceptions would be less troublesome.

Contents

Background

Review of Exception Handling Basics

The Requirements

The Three-tiered Exception Handling Architecture

Summary