Pros and cons of custom exceptions [duplicate]

Question

This may be an pointless question based on opinion, style, and context but I've been racking my brain trying to decide whether or not to make use of custom exceptions and would love to hear some pros and cons from anyone with experience from both approaches.

For example I'm trying to decide between a custom ObjectNotFoundException vs IllegalArgumentException/IllegalStateException.

(Please note that I am not intending to throw an exception whenever a service cannot find an object with a given identifier. We simply return a null in that case. I'm speaking of when an action is to be performed on an object with a given identifier. In this case, the object in question is expected to exist, so if it does not, we want to throw an exception.)

On one hand, a "GiraffeNotFoundException" is explicit and could be handled differently than a generic IllegalStateException, but then again I suppose that would only matter if such a differentiation is actually required. Another pro is that a custom message for such an exception can be set as the default message for this exception (reducing a bit of redundancy).

On the other hand, it might not be a good idea to clutter the source code with custom exceptions. Also with standard exceptions, the Assert class from spring can be used quite efficiently. There are no intentions of publishing our code as a third party library so there are no pressures for using standard exceptions from that end.

Any other thoughts?

Answer 1

In my experience that depends on how much you need to do once you caught the exception.

If you need to just propagate it further after closing some resources - there is no need to make your own exceptions.

If you need to do some complex work depending on what failed and how - custom exceptions are your friend. If you just use a single IllegalArgumentException - how do you know if it's your DB that failed or network or disk? When looking through logs you will certainly see your very useful debug message, but the code needs that info there and then, and exception type is the perfect tool for it.

Another feature that you haven't mentioned is an exception hierarchy. Different implementations of a method can throw more specific exceptions. It is also easier to catch a group of exceptions by catching their superclass (up to a point of course, catch(Throwable e) is an antipattern).

Lastly: If you make your own hierarchy, you don't have clashes. In the simplest example where you need to provide a meaningful message when an object is not found, it would be pretty embarrassing to give a message saying "Failed to find object: Object cannot be added to list" because it was actually thrown by a List.add(e) method, not your method...