Published in NDC Magazine (The Developer, 2014/3)

1. One of the hardest things in software development
is naming. Naming of products, of paradigms and of
parts of your code. The reason naming is both hard
and important is because it is an act of communication;
without good names your code might as well be
written in, well, code.
©totallyPic/Shutterstock
By Kevlin Henney
EXCEPTIONAL
NAMING
48

2. We often adopt conventions to make
some aspects of naming easier, but
while such consistency is often a good
thing, some practices are flawed from
the outset. Although having a com-
mon vocabulary of concepts is useful
across a codebase, the basis of the
consistency must be useful other-
wise it's just noise and can become
homeopathic: programmers make
names longer by adding more words
but end up diluting the meaning of
their code with every Factory/Man-
ager/Object/Controller/Aggregate/
Value they add.
One such ritual common to both the
.NET and the Java worlds is adding
the suffix Exception to a class to
denote that its instances are excep-
tions. Exceptions are privileged in the
language, meaning that they appear in
specific and compiler-enforced places
in your code: in a throw, in a catch and,
in the case of the Java, in a throws list.
By definition things that appear in
these places can only be exceptions;
the reader already knows they are
exceptions, so there's nothing more
to add.
Of course, there is also the definition
of the exception class. That a class is
an exception should be obvious either
by its parentage or by its name. The
name should represent whatever the
problem is, and should do so directly
and precisely.To add Exception to the
end is either redundant — so remove it
— or an indication of a poor name — so
rename it. Consider, for example, the
following core Java exception classes:
ClassNotFoundException
EnumConstantNotPresentException
IllegalArgumentException
IllegalAccessException
IndexOutOfBoundsException
NegativeArraySizeException
NoSuchMethodException
TypeNotPresentException
UnsupportedOperationException
Dropping the Exception suffix gives
the following names:
ClassNotFound
EnumConstantNotPresent
IllegalArgument
IllegalAccess
IndexOutOfBounds
NegativeArraySize
NoSuchMethod
TypeNotPresent
UnsupportedOperation
These names are more concise and
perfectly descriptive. There is no
question that these are exceptions.
OK, but what about the following, also
from the core Java exception classes?
ArithmeticException
ArrayStoreException
ClassCastException
InstantiationException
NullPointerException
SecurityException
Dropping the Exception suffix results
in the following:
Arithmetic
ArrayStore
ClassCast
Instantiation
NullPointer
Security
Hmm, not so good. But is that a prob-
lem with dropping the Exception suf-
fix?Oraproblemrevealedbydropping
it? Let's try renaming these classes
to the exceptions they actually rep-
resent:
IntegerDivisionByZero
IllegalArrayElementType
CastToNonSubclass
ClassCannotBeInstantiated
NullDereferenced
SecurityViolation
These names are both accurate and
precise, representing the actual
exception condition without resorting
tonoisewords.Isitanexceptionthata
reference (or rather, a pointer) is null?
Not at all: the exception is only thrown
when a null is dereferenced, such as
having a method called through it.
Is security an exception? Not at all:
a security violation is what is being
signalled. Of particular interest is
renaming ArithmeticException to
IntegerDivisionByZero, which clari-
fies something many Java program-
mers are unaware of!
Just as you don't tag your verbs with
Verb or your nouns with Noun when
you write or speak, there is little rea-
son — and many reasons not to — tag
Exception onto the end of an exception
class's name. In many cases it can be
considered a code smell rather than
a practice to follow, and can deprive
programmers of the opportunity to
choose a better name. The possible
exception to this rule? The general
class that indicates that its descend-
ants are exceptions: Exception. But
thenagain,that'snotasuffix:that'sthe
whole of its name and the concept that
it represents, so perhaps there are no
exceptions on Exception naming.
49
Kevlin is an independent
consultant and trainer based
in the UK. His development
interests are in patterns,
programming, practice and
process. He has been a columnist
for various magazines and web
sites, including Better Software,
The Register, Application
Development Advisor, Java
Report and the C/C++ Users
Journal. Kevlin is co-author
of A Pattern Language for
Distributed Computing and
On Patterns and Pattern
Languages, two volumes in
the Pattern-Oriented Software
Architecture series. He is also
editor of the 97 Things Every
Programmer Should Know site
and book.