Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Specifying a suffix of Exception on exception classes feels like a code smell to me (Redundant information - the rest of the name implies an error state and it inherits from Exception). However, it also seems that everyone does it and it seems to be good practice.

I am looking to understand why this is good practice.

I have already seen and read the question why do exceptions usually have the suffix exception in the class name

The question is for PHP and while the responses are probably valid for Java. Are there any other arguments or is it really as simple as explicitly differentiating them?

If we take the examples from the previous question - could there really be classes in java with the name FileNoFound that is not an exception? If there could be, does it warrant suffixing it with Exception ?

Looking at a quick hierarchy in eclipse of Exception, sure enough, the vast majority of them do have the suffix of exception, but there are a few exceptions. javassist is an example of a library that seems to have a few exceptions without the suffix - e.g. BadByteCode, BadHttpRequest etc.

BouncyCastle is another lib with exceptions like CompileError

I've googled around a bit as well with little info on the subject.

share|improve this question
"Should all exceptions carry an Exception suffix, or should we make exceptions for exceptional exceptions?" ;) – tdammers Feb 21 '13 at 21:13
actually Error is like Exception (see OutOfMemoryError) but they are meant for things that are hard to recover from (so you almost never deal with them) – ratchet freak Feb 21 '13 at 21:17
Also, I've heard that as a general rule 'classes should be nouns and methods should be verbs (actions)'. FileNotFound ArrayIndexOutOfBounds and OutOfMemory are more observations/descriptions, but are then applied to the noun Exception. – mikeTheLiar Feb 21 '13 at 21:47
up vote 14 down vote accepted

Landei's answer is a good one, but there's also the grammatical answer. Class names should be nouns. What is an "OutOfMemory"? What is a "FileNotFound"? If you think of "Exception" as the noun, then the descriptor is the adjective specifying it. It's not just any Exception, it's a FileNotFoundException. You shouldn't need to catch an OutOfMemory any more than you'd go to the store to buy a "blue".

This also shows up if you read your code as a sentence: "Try doing ..., and catch OutOfMemory Exceptions"

share|improve this answer

I think exceptions (and errors, and theoretically other Throwables) are different from things like interfaces or enums (which usually ain't used as suffix): They have usually a very clear and limited purpose, they are used with specialized language constructs (try, catch, throw, throws) and follow special rules (e.g. checked vs unchecked exceptions, no generics). In a way they are not just classes that happen to be used as exceptions, but an exception mechanism which is implemented by the means of classes.

So if you dealing with an exception and don't recognize it as such, usually something is deeply wrong (which is again not the case for things like enums or interfaces). So I think these differences to "normal" classes are big enough to call for a visual clue.

share|improve this answer
Sounds self-contradicting to me. If exceptions are that special and used in special ways and so obviously recognizable, why do you need a visual clue for? – Michael Borgwardt Feb 21 '13 at 22:04
@MichaelBorgwardt - I think he's saying that because they're special and used in special ways, they should have the visual clue to be obviously recognizable. That being said, I don't know whether you even can throw something that isn't inherited from Exception in Java - you can't in C#. If you can't, then I can't think of a scenario where you'd be "dealing with an exception and [not] recognize it as such". – Bobson Feb 21 '13 at 22:30
You can't throw non-Throwables in Java, either. However you may deal with exception not only in try-catch-settings, e.g. you might collect exceptions when you make some kind of validation for complex objects (when you want to know all related problems, not only the first one). In such cases you should be aware that you can e.g. re-throw the things you have in your list, so it would be bad to call them i.e. ValidationIssue instead of ValidationException. – Landei Feb 22 '13 at 7:22

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.