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

In general exceptions are extremely expensive in Java and should not be used for flow control!

The point of exception is to describe something exceptional, for example NumberIsZeroException isn't really that exceptional while PlanesWingsJustDetachedException clearly is something truly exceptional. If it's really exceptional in your software that user is null because there's data corruption or id number doesn't match anything or anything like that then it's alright to use an exception for that.

What exceptions also cause is divergence from "the happy path". While this doesn't apply to your example code, sometimes it's very beneficial to use Null Object instead of returning plain null.

Answer 2

As per your last edit. I think ( as Tony suggested ) using the NullObject pattern would be more useful here.

Consider this third scenario:

class NullUser extends User {

    public static NullUser nullUser = new NullUser();

    private NullUser(){}

    public int getAge() {
        return 0;
    }
}

//Later...
int age;

User user = getUser("adam"); // return nullUser if not found.
age = user.getAge();         // no catch, no if/null check, pure polymorphism

Answer 3

How would such a design approach effect performance? Do the benefits out-weigh the cost or is it just plain bad coding?

I'd said that there is almost no benefit of this programming style. Exception should be understood as (well...) exception. It should only should happen in a non-normal situation. How do you define 'normal situation' is pretty much arguable thought...

Answer 4

Creating an exception, throwing an exception (with a stack trace), catching an exception and then garbage-collecting that exception (eventually) is much slower than doing a simple if check.

Ultimately, you can probably argue it down to style, but I think it's very bad style.

Answer 5

Personally, I think that's a bad and obnoxious idea.

The usual way to encourage people to check for null values is to use annotations like @Nullable (and its opposite, @NotNull, for functions that are guaranteed to return non-nulls). By setting up similar annotations on parameters (so that parameter expectations are set), quality IDEs and bug-checkers (like FindBugs) can then generate all the necessary warnings when the code doesn't do enough checking.

Those annotations are available in JSR-305, and apparently there is also a reference implementation.

---

As far as performance goes, creating the exception is the expensive part (I've read that it's due to the stacktrace-filling, among other things). Throwing the exception is cheap, and is a control-transfer technique used in JRuby.

Answer 6

There is a performance penalty to throwing an exception, but that's usually acceptable because the exception handling code only executes in exceptional cases. If you start using exceptions for flow control, you're turning the usual case around and making them expected behavior. I'd strongly recommend against it.