The Benchmark

To test how much of an impact this has, I developed a simple JMH benchmark.

Benchmark                                     Mode  Cnt     Score    Error  Units
ReturnVsException.testException              thrpt  100    42.724 ±  2.056  ops/s
ReturnVsException.testFastException          thrpt  100  2014.997 ± 15.174  ops/s
ReturnVsException.testReturn                 thrpt  100  5492.222 ± 60.231  ops/s

I used the following code to perform this benchmark,

private int index;

@Setup(Level.Iteration)
public void setup() {
    index = 0;
}

@Benchmark
public void testReturn() {
    performReturn();
}

@Benchmark
public void testException() {
    try {
        performException();
    } catch (Exception e) {
    }
}

@Benchmark
public void testFastException() {
    try {
        performFastException();
    } catch (Exception e) {
    }
}

private boolean performReturn() {
    index ++;

    return index % 5 != 0;
}

private void performException() throws Exception {
    index ++;

    if (index % 5 == 0) {
        throw new IllegalArgumentException();
    }
}

private void performFastException() throws Exception {
    index ++;

    if (index % 5 == 0) {
        throw new FastIllegalArgumentException();
    }
}

public static class FastIllegalArgumentException extends IllegalArgumentException {

    @Override
    public synchronized Throwable fillInStackTrace() {
        return null;
    }
}

Now, this is a basic test that returns a Boolean. If you were to replace exceptions with returns, you'd generally create an enumeration or similar for each API call to indicate different responses.

The following is a modified version of the test that returns an enumeration rather than a Boolean value, and the results are similar.

Benchmark                                     Mode  Cnt     Score    Error  Units
ReturnVsExceptionAdvanced.testException      thrpt  100    18.128 ±  0.269  ops/s
ReturnVsExceptionAdvanced.testFastException  thrpt  100   915.171 ±  9.073  ops/s
ReturnVsExceptionAdvanced.testReturn         thrpt  100  5491.713 ± 66.110  ops/s

I used the following code to perform this benchmark,

private int index;

@Setup(Level.Iteration)
public void setup() {
    index = 0;
}

@Benchmark
public void testReturn() {
    performReturn();
}

@Benchmark
public void testException() {
    try {
        performException();
    } catch (Exception e) {
    }
}

@Benchmark
public void testFastException() {
    try {
        performFastException();
    } catch (Exception e) {
    }
}

private APIResponse performReturn() {
    index ++;

    if (index % 5 == 0) {
        return APIResponse.TEST_1;
    } else if (index % 3 == 0) {
        return APIResponse.TEST_2;
    } else {
        return APIResponse.SUCCESS;
    }
}

private void performException() throws Exception {
    index ++;

    if (index % 5 == 0) {
        throw new IllegalArgumentException("Test 1");
    } else if (index % 3 == 0) {
        throw new IllegalArgumentException("Test 2");
    }
}

private void performFastException() throws Exception {
    index ++;

    if (index % 5 == 0) {
        throw new FastIllegalArgumentException("Test 1");
    } else if (index % 3 == 0) {
        throw new FastIllegalArgumentException("Test 2");
    }
}

public static class FastIllegalArgumentException extends IllegalArgumentException {

    public FastIllegalArgumentException(String s) {
        super(s);
    }

    @Override
    public synchronized Throwable fillInStackTrace() {
        return null;
    }
}

private enum APIResponse {
    TEST_1,
    TEST_2,
    SUCCESS
}

Discussion

Both scores are slightly lower than the previous test. However, this is partially due to the extra modulo operation. In the case of the exception test, more exceptions are thrown than in the previous test. This finding highlights a critical detail and caveat of using exceptions. The performance varies greatly depending on whether it threw an exception or not.

Overall there's a difference of over 300x between the exception and return flow control types. Both methods allow the same level of control, yet one performs much better.

Both benchmarks also test what is often cited as a solution to this issue, creating a custom exception class to remove the stack trace generation. The 'fastException' test shows this case. Whilst this drastically speeds up exceptions, it still doesn't perform on the same level as returns.

If you've currently got a massive application using exceptions in places like this, I'm not suggesting replacing it all with return statements. However, if you do end up having performance issues, this is an excellent place to start.

Slow exception calls are often a symptom of a more significant problem of poor application design. Exceptions are intended for exceptional circumstances, not flow control. If thrown exceptions are occurring enough to cause noticeable performance degradation, they're likely not used for purely exceptional circumstances.

"exceptions are, as their name implies, to be used only for exceptional conditions; they should never be used for ordinary control flow".

(Quote from Effective Java (2nd Edition) (The Java Series) (2008) by Joshua Bloch)