Performance cost of coding “exception driven development” in Java?

Question

Are there are any performance cost by creating, throwing and catching exceptions in Java?

I am planing to add \'exception driven development\' into a larger project.

Answer 1

There is a performance cost but that is not the main issue. Do you really want your code littered with catch blocks like your example? That's horrible.

Usually a web application has a main exception handler where everything uncaught ends up, at least that way when there is a mistake processing gets cut off cleanly. With all this exception-catching going on your process flow is going to be like falling down a couple flights of stairs.

Some exceptions are very special cases that you expect and can handle. However, in general exceptions pop up when something unexpected or uncontrollable went wrong. From that point your objects are likely to be in a bad state, because subsequent steps will expect things to be there that didn't happen due to the exception, and trying to proceed will only trigger more exceptions. It's much better to let unexpected exceptions go so they can be caught by a central handler.

Answer 2

Building a stack trace amounts to about a thousand basic instructions. It has a definite cost.

---

Even though you don't ask, many people will probably tell you the approach you envision does not seem very attractive ... :-(

The code you are forcing on your callers is really ugly, hard to write and maintain.

To be more specific, and try to get understood, I will try to highlight several points.

• The other developer is responsible for checking the nullity of the User received from your API (if the documentation states it clearly). His code does such checks internally regularly, so he can do it also after a call to your API. Even more, that will give his code some homogeneity.

• When reusing an existing exception is appropriate, it is much better than creating your own. For example, if it was an error to call your API and ask for an non-existing User, you can throw an IllegalArgumentException.

Answer 3

"which would result in NullPointerException and a crash."

a NullPointerException is an exception, and can be caught in the a catch.

So the additional exception is redundant unless it adds clarity to the code. In this instance, it really doesn't. In fact, you've just taken an unchecked programmer error exception and promoted it to a checked exception.

Creating a checked exception for a programmer's error actually means your code has to explicitly handle the possibility that the programmer introduced an error, when they haven't.

Answer 4

Exceptions cost a lot because each time an exception is thrown, the stack trace must be created and populated.

Imagine a balance transfer operation which fails in 1% of cases due to lack of funds. Even with this relatively little rate of failures, performance may be severely impacted. See here for the source code and benchmark results.

Answer 5

See this answer about performance with exceptions.

Basically in your idea you are wrapping a RuntimeException, NullPointerException, into a checked Exception; imho I would say that the problem can be managed at the business level with an ObjectNotFoundException: you did not find the user, the fact that user is null and that this generates errors comes after.

Answer 6

You could forget about exceptions and avoid such a performance concern. This makes your API speak for itself.

int getUserAge(String userName) 
{
    int age = 0;
    UserSearchResult result = getUser(userName);
    if (result.getFoundUser())
    {
        User user = result.getUser();
        age = user.getAge();
    }
    return age;
}