“You don’t have to pay programmers. They’ll do it for free.”

Don’t get me wrong. He’s a nice guy. I still see him even after we’ve both left the company. It’s just that he had a bad sense of humor. But, it wasn’t far from the truth. Many of us enjoy programming. If we didn’t have to earn a living, I’m sure many of us would do it in our spare time for free.

Unfortunately, there are some areas that don’t get focused on as much as others. One such area is the handling of exceptions. I actually think that these are the areas that distinguish professional-like [i] engineers from amateur-like people. Many people find joy and are productive in writing the regular path of a program, but once they get into perfecting the system, they drop in performance. Some even resist doing it. Many of us need to get paid to do it.

Not only does exception handling lack attention, it’s also confusing the way it is presented. Exception handling mechanisms standard in programming languages don’t provide a full conceptual framework to work on. Even the greatest people in the standards committee seem to try to avoid the work, and just copy a mechanism from another language.

[i] I have to call these people “professional-like”, because there are people, who aren’t paid, but produce work that can be labeled professional.

Contents

Background

Review of Exception Handling Basics

• The Usual Mechanism
• Inheritance in Exception Handling
• The Problem with the Standard Exception Hierarchy
• Hierarchy without Polymorphism?

The Requirements

• Determining How to Process the Exception
• Present the Error to the User
• Pass Additional Information to the Caller
• Representing the Cause of the Error for the Developer

The Three-tiered Exception Handling Architecture

• The Library Layer
• The Logic Layer

• • Conversion of Exceptions
  • Recovery
  • Other Languages
  • Dictionaries for Attributes
• The Presentation Layer

• • Messages and Errors
  • Generating Messages

Summary