Is it a good practice to have specific Exceptions for everything? Or is it better to reuse a bit more abstract exception?

Question

Hi!

I am dealing with a project, in wich I have written one Exception for each possible exception situation. The point is that I find it more "readable", but I am getting an insane amount of different exceptions.

Is it considered a good practice to do it like that? Or should I write just exceptions a bit more abstract, in order to have not so many?

Thanks a lot for your time.

Answer 1

Why not just create a small number of exceptions and let them take a descriptive string in the constructor?

throw new GenericException("Error: problem with....");

And have the toString() method print out the string you passed it.

Answer 2

Which is better depends on the likelihood that your code is going to catch the specific exceptions. If you are only ever likely to catch (or discriminate in some other way) the more general (superclass) exceptions, then having lots of more specific (subclass) exceptions doesn't achieve much. In that case, it is probably better to define fewer exceptions and use exception messages to express the finer details of what has gone wrong.

On the other hand, if specific exceptions already exist, it makes sense to use them. Just throwing java.lang.Exception or java.lang.RuntimeException is plain lazy, IMO.

FOLLOW UP

Well, I am catching always specific exceptions, but the thing is that, in other "catches" I use also specific exceptions that are kind of similar (they can refer to "database" for example, but they are not same). So the question is if it should be a good thing do a "DatabaseException", and use it, instead of "DatabaseConnectionException" and "DatabaseDataException" for example, wich is more readable, but at the end i got millions of explicit exceptions.

If your code frequently looks like this:

try {
    ... 
} catch (DatabaseConnectionException ex) {
    // do something
} catch (DatabaseDataException ex) {
    // do same thing
} catch (DatabaseTangoException ex) {
    // do same thing
}

... then your fine grained exceptions are not helping. But if it looks like this:

try {
    ... 
} catch (DatabaseConnectionException ex) {
    // do something
} catch (DatabaseDataException ex) {
    // do something completely different
} catch (DatabaseTangoException ex) {
    // do something totally extraordinary
}

... then maybe your fine-grained exceptions are working for you. And if you declare these three exceptions as subclasses of DatabaseDataException, then you can handle the cases together or separately as the circumstances dictate.

Really, it is up to you to make your own judgement, in the context of your application.

Answer 3

I think it is a good practice to have specific exceptions whenever possible.

By following this practice we give different error messages based on the exception type.

Even programming languages like Java are also supporting this concept, by allowing programmers to extend Exception class and create their own Exception subclasses.

You can get more INFO from the following question as well. http://stackoverflow.com/questions/2308979/exception-handling-question

Answer 4

I would suggest having an abstract DomainException (where domain reflects your organization or the application layer in which the problem is), which all your specific exceptions extend.

Then you can just catch DomainException to say that this is a problem with your code, and then refine if needed.

Answer 5

Bloch, J., 2008. Effective Java. 2nd ed:

Item 60: Favor the use of standard exceptions

Reusing preexisting exceptions has several benefits. Chief among these, it makes your API easier to learn and use because it matches established conventions with which programmers are already familiar. A close second is that programs using your API are easier to read because they aren’t cluttered with unfamiliar exceptions. Last (and least), fewer exception classes mean a smaller memory footprint and less time spent loading classes.

Answer 6

That you can extend exceptions does not mean that you should. Dogbane's answer gives good reasons for using standard exceptions. (Note that he says using "standard" exceptions, not "generic"! Use as specific a standard exception as you can find.)

I believe that you should use your own exception subclass only when both of these conditions are true:

• You want to do something specific when you catch a certain category of exceptions; using a specific subclass in that case lets you catch it while letting other exceptions bubble up without problem.
• No standard exception covers your category with enough accuracy.