7

How much longer (in nanoseconds) does a try-catch take when catching an exception rather than doing a check (assuming message has HashMap type performance for lookup)?

    try {
        timestamp = message.getLongField( MessageField.TIMESTAMP );
    } catch (MissingDataException e) {
        //Not all messages contain this field
    }

vs

if (message.contains(MessageField.TIMESTAMP))
    timestamp = message.getLongField( MessageField.TIMESTAMP );
DD.
  • 21,498
  • 52
  • 157
  • 246
  • It's going to vary a lot base of JVM, underlying hardware etc. Have you tried measuring it yourself? – Sean Nov 24 '11 at 10:56
  • 1
    Is that an exceptional situation? Do you need to log it as an error? Does this code run in a loop? – Denis Tulskiy Nov 24 '11 at 10:56
  • Possilbe duplicate: http://stackoverflow.com/questions/4280831/java-try-catch-performance-is-it-recommended-to-keep-what-is-inside-the-try-cla & http://stackoverflow.com/questions/5158665/java-try-catch-blocks – Alex K Nov 24 '11 at 11:15

4 Answers4

25

In short, the check is way faster. You should use the check because:

  • Exceptions are EXPENSIVE! A stack trace must be created (if used, eg logged etc) and special flow control handled
  • Exceptions should not be used for flow control - Exceptions are for the "exceptional"
  • Exceptions are the code's way of saying "I can't handle this situation and I'm giving up... you deal with it!", but here you can handle it... so handle it
Bohemian
  • 412,405
  • 93
  • 575
  • 722
  • In some circumstances the exception may be optimised away, so it is not necessarily slower in all cases. – Tom Hawtin - tackline Nov 24 '11 at 12:37
  • 2
    +1: The stack trace is not fully created until it is used (as for most exceptions its not needed) All the same exceptions are not just expensive but should be for exceptional conditions. – Peter Lawrey Nov 24 '11 at 19:12
  • @PeterLawrey Thanks - I didn't know about stacktraces not being created until used – Bohemian Nov 24 '11 at 22:49
3

The answer is "much longer". Exceptions are slow compared to a check due to time to build the stacktrace.

As a general point using exceptions to control program flow is a bad idea as it clutters the code up. Always do the check and leave exceptions for when "exceptional" things happen.

Mike Q
  • 22,839
  • 20
  • 87
  • 129
3

Another answer is "Who cares!". It's wrong!

In any case, if you want to benchmark it, use https://github.com/google/caliper

alex
  • 5,213
  • 1
  • 24
  • 33
  • Anyone done this? I assume the cost of try is trivial, the cost of throw(e) ... catch(Exception e) {} is quite expensive so you only want to use the construct for infrequent (ie: exceptional) situations. but how does a "try" perform relative to lets say a test (if(x)), add (i += j), etc. I woudl think it somewhere in maype 1 to 5x that ammount if implemented well. – peterk Sep 23 '14 at 10:13
  • is caliper still maintained? in my case it throws an `NoSuchMethodError` – Joel Jul 13 '15 at 17:03
  • It seems to have moved to Github. Updated the link – alex Jul 14 '15 at 10:05
1

Would like to quantify this...

It is literally impossible to quantify in general. Not in nanoseconds ... because it depends on the execution platform. And not even in percentage terms.

The time depends largely on the time taken to capture the stack trace, and that depends on how deep the stack is when the exception is thrown. And that's just one of the reasons that using Java exceptions instead of regular conditional statements is a really bad idea.

But the flip side is that there is scope for the JIT compiler to heavily optimize exception-related code provided that it can determine that the stack trace for and exception thrown at a particular point is never going to be used.

If you really want some (IMO, pointless and largely meaningless) numbers, you will need to do your own benchmarking. Good luck.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216