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.

© to

tally

Pic/

Shu

tter

stoc

k

By Kevlin Henney

EXCEPTIONAL NAMING

48

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: ClassNotFoundExceptionEnumConstantNotPresentExceptionIllegalArgumentExceptionIllegalAccessExceptionIndexOutOfBoundsExceptionNegativeArraySizeExceptionNoSuchMethodExceptionTypeNotPresentExceptionUnsupportedOperationException Dropping the Exception suffix gives the following names: ClassNotFoundEnumConstantNotPresentIllegalArgumentIllegalAccess

IndexOutOfBoundsNegativeArraySizeNoSuchMethodTypeNotPresentUnsupportedOperation 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? ArithmeticExceptionArrayStoreExceptionClassCastExceptionInstantiationExceptionNullPointerExceptionSecurityException Dropping the Exception suffix results in the following: ArithmeticArrayStoreClassCastInstantiationNullPointerSecurity Hmm, not so good. But is that a prob-lem with dropping the Exception suf-fix? Or a problem revealed by dropping it? Let's try renaming these classes to the exceptions they actually rep-resent: IntegerDivisionByZeroIllegalArrayElementTypeCastToNonSubclassClassCannotBeInstantiatedNullDereferencedSecurityViolation These names are both accurate and precise, representing the actual exception condition without resorting to noise words. Is it an exception that a 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 then again, that's not a suffix: that's the 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.