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.
3
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“
9
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.
3
It’s redundant if you know it is an exception. In reality, I would expect that say “FileNotFound” is an enum, and not a subclass of Exception. And then I would be wondering “how on earth can I throw a FileNotFoundException when I looked for a file and got a FileNotFound error? “
However, it also seems that everyone does it and it seems to be good practice.
Yes, everyone does it indeed, so it’s a practice, but is it still good? Several people are questioning that:
- http://mnapoli.fr/approaching-coding-style-rationally/ (The Exception suffix § context: php)
- the linked video, https://vimeo.com/album/2661665/video/74316116 (skip to 53:00, context: c++), inspires the article and makes the point that every time you use an exception, you have a keyword that already shows it is an exception nearby
- http://verraes.net/2013/10/verbs-in-class-names/ shows how the statement in @Bobson ‘s answer might not be an absolute, and makes the point that sometimes the suffix is good, for application or infrastructure level exceptions, and sometimes you should try to save the characters taken by this long suffix to express something more precise and meaningful. This point only make sense if you use a language where the culture is to use exceptions for business rules violations.
- the SO link you provide makes points about name conflicts, but now, we have namespaces, don’t we?
2