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
    "Should all exceptions carry an Exception suffix, or should we make exceptions for exceptional exceptions?" ;)
    – tdammers
    Commented Feb 21, 2013 at 21:13
  • 2
    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) Commented Feb 21, 2013 at 21:17
  • 1
    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. Commented Feb 21, 2013 at 21:47

4 Answers 4


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"

  • 1
    To quote the article "Try to use nouns because a class is normally representing something in the real world". But do exceptions fall into this case? For me, they are more like a programming artefact, representing an error message. "You will get an OutOfMemory exception" reads better than "You will get an OutOfMemoryException exception", doesn't it?
    – greg0ire
    Commented Jul 19, 2016 at 17:55
  • 1
    @greg0ire - You should try it as "You will get an OutOfMemoryException." That said, we also have PIN numbers and ATM machines, so an OOME exception wouldn't be that unusual.
    – Bobson
    Commented Jul 19, 2016 at 17:57
  • I think the point you are making here is really the best one (the one about name conflicts does not hold anymore thanks to namespaces, at least in php). I have more things to say about all this, and will post an answer soon.
    – greg0ire
    Commented Jul 19, 2016 at 18:00
  • Done! What do you think?
    – greg0ire
    Commented Jul 19, 2016 at 18:12
  • 1
    @MatthieuNapoli - We don't use Class as a suffix because Dog, Cat, and XmlReader are already nouns. OutOfMemory is an adjective. As for Kingdom of Nouns, the issue isn't that everything in an object oriented language is a noun - if you don't like that, you use a language which isn't strictly OO. Instead, the issue is that Java's idioms are excessively verbose. C# is just as OO as Java, but tends to be more concise.
    – Bobson
    Commented Jul 19, 2016 at 22:34

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.

  • 1
    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? Commented Feb 21, 2013 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
    Commented Feb 21, 2013 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
    Commented Feb 22, 2013 at 7:22

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?
  • 1
    This is a java question, not a php one. Idioms are different between languages. That said, I strongly disagree with this quote from your third link: "Exceptions can be similar to events, ... with the nuance that it is an undesirable event, a warning that some operation was inconsistent with, for example, business rules that are in effect." Maybe PHP is different about this, but to my mind, exceptions are supposed to be exceptional. If a business rule is violated in any expected way, your normal logic should handle it - it's not an exception to normal behavior.
    – Bobson
    Commented Jul 19, 2016 at 22:47
  • You may be right in that it varies on a language-per-language basis : see this thread about python : gossamer-threads.com/lists/python/python/796627 . php and python are clearly not performance-focused, that maybe why there is this difference with java (which is performance-focused, right?). If you have several layers to cross in your call stack before being at the right level to handle the business rule violation properly, exceptions are best IMO. It also makes return types more consistent (you return always the same type, not false or true). I will edit my answer this into account
    – greg0ire
    Commented Jul 20, 2016 at 10:20

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