Do you write exceptions for specific issues or general exceptions?

Question

I have some code that gives a user id to a utility that then send email to that user.

emailUtil.sendEmail(userId, "foo");

public void sendEmail(String userId, String message) throws MailException {
    /* ... logic that could throw a MailException */
}

MailException could be thrown for a number of reasons, problems with the email address, problems with the mail template etc.

My question is this: do you create a new Exception type for every one of these exceptions and then deal with them individually or do you create one MailException and then store something in the exception (something computer-readable, not the description text) that allows us to do different things based on what actually happened.

Edit: As a clarification, the exceptions aren't for logs and what-not, this relates to how code reacts to them. To keep going with the mail example, let's say that when we send mail it could fail because you don't have an email address, or it could because you don't have a valid email address, or it could fail.. etc.

My code would want to react differently to each of these issues (mostly by changing the message returned to the client, but actual logic as well).

Would it be best to have an exception implementation for each one of these issues or one umbrella exception that had something internal to it (an enum say) that let the code distinguish what kind of issue it was.

Answer 1

In my code, I find that MOST exceptions percolate up to a UI layer where they are caught by my exception handlers which simply display a message to the user (and write to the log). It's an unexpected exception, after all.

Sometimes, I do want to catch a specific exception (as you seem to want to do). You'll probably find, however, that this is somewhat rare and that it is indicative of using exceptions to control logic -- which is inefficient (slow) and often frowned upon.

So using your example, if you want to run some special logic when the email server is not configured, you may want to add a method to the emailUtil object like:

public bool isEmailConfigured()

... call that first, instead of looking for a specific exception.

When an exception does happen, it really means that the situation was completely unexpected and the code can't handle it -- so the best you can do is report it to the user (or write it to a log or restart )

As for having an exception hierarchy vs exceptions-with-error-codes-in-them, I typically do the latter. It's easier to add new exceptions, if you just need to define a new error constant instead of a whole new class. But, it doesn't matter much as long as you try to be consistent throughout your project.

Answer 2

I usually start with a general exception and subclass it as needed. I always can catch the general exception (and with it all subclassed exceptions) if needed, but also the specific.

An example from the Java-API is IOException, that has subclasses like FileNotFoundException or EOFException (and much more).

This way you get the advantages of both, you don't have throw-clauses like:

throws SpecificException1, SpecificException2, SpecificException3 ...

a general

throws GeneralException

is enough. But if you want to have a special reaction to special circumstances you can always catch the specific exception.