The Exception to the Rule: Why Suffixing 'Exception' in Class Names Is a Code Smell

Article illustration 1

In software development, naming isn't just labeling—it's an act of communication that shapes mental models. As Kevlin Henney argues in his incisive critique, one pervasive habit sabotages this communication: mechanically appending "Exception" to exception class names. This practice, ingrained in Java and .NET cultures, represents a critical failure in semantic design.

The Redundancy Trap

"A naming convention should not be used to prop up weak names. If a name doesn't communicate well, we need to see that clearly so we can address it rather than smothering it."

Modern languages already signal exception contexts syntactically—through throw/catch keywords and compiler checks. Suffixing classes with "Exception" is like tagging nouns with "Noun" in natural language: it wastes conceptual bandwidth. Henney identifies this as homeopathic naming—adding words dilutes meaning rather than enriching it, violating the DRY principle's core tenet: avoid duplicating knowledge.

Case Study: Java's Standard Library

Consider these standard Java exceptions without their suffixes:

// Original:
ClassNotFoundException
IndexOutOfBoundsException

// Stripped suffix:
ClassNotFound
IndexOutOfBounds

These remain unambiguous—their names inherently convey failure. But others reveal weaknesses when stripped:

NullPointerException → NullPointer
SecurityException → Security

The vagueness isn't caused by removing "Exception"; it's exposed by it. "NullPointer" doesn't specify whether it indicates illegal dereferencing or invalid argument passing. Henney proposes precise alternatives:

  • NullPointerException → UnexpectedNullReference
  • SecurityException → SecurityViolation
  • NumberFormatException → InvalidNumberFormat

The .NET Distinction

Unlike Java, .NET differentiates between:

  • NullReferenceException (dereferencing null)
  • ArgumentNullException (passing null argument)

This specificity avoids ambiguity—a lesson Java could embrace. Precise naming forces critical distinctions, improving exception handling semantics.

The Path Forward

  1. Eliminate mechanical suffixes: Let context and inheritance define exceptions.
  2. Use negative language: Words like "Invalid," "Missing," or "Violation" signal problems inherently.
  3. Treat vagueness as a design smell: Ambiguous names often indicate unclear error models.

As Henney concludes, just as we don't suffix verbs with "Verb," appending "Exception" squanders an opportunity for clarity. By naming exceptions for what went wrong rather than what they are, we transform noise into signal—elevating exceptions from syntactic necessities to meaningful conversations about failure.

Source: Adapted from Kevlin Henney's Exceptional Naming