7

What costs for sure less time for execution between the two options:

A:

if(something!=null){
    ...
}else{
    //log
}

or:

B:

try{
    something.getField();...
}catch(Exception e){
    //log
}
BackSlash
  • 21,927
  • 22
  • 96
  • 136
Roxana
  • 1,569
  • 3
  • 24
  • 41
  • 2
    As an aside you should never catch the base Exception. As others have said the Exception option is more expensive, but if you really need to catch an exception here you should catch NullReferenceException. – Kev Jun 18 '14 at 12:06
  • ... When you catch an exception, you're stating that you expected this exception, and you know how to deal with it. The code above implies that you know to deal with any situation. – Kev Jun 18 '14 at 12:16
  • @BlackKnight, there is no `NullReferenceException` in java unlike c#, and you should never catch directly a NPE unless you have to make some workaround. Catching `Exception` is fine as long as you can ensure you can live with the lack of result/partial completion/etc. – bestsss Jun 18 '14 at 17:10
  • @bestsss That's right, I guess I still have my C# brain in. NullPointerException would be the Java equivalent. – Kev Jun 20 '14 at 11:05

3 Answers3

16

if definitely.

Throwing an exception is a costly operation and this is not the purpose of Exception.

The purpose of Exception is to catch exceptional condition that may arise at runtime but you shouldn't code to generate exception to make that decision.

Kev
  • 2,656
  • 3
  • 39
  • 63
jmj
  • 237,923
  • 42
  • 401
  • 438
  • 1
    One exception to this is maybe trying to find out if a string is a number – blank Jun 13 '14 at 07:38
  • @blank: y u no regex? – hiergiltdiestfu Jun 13 '14 at 07:39
  • 1
    this is completely correct. and you can verify this if you use your debugger. look at the exception that is created by your code, it stores some good amount of information. this has to be created at a time, and this is where your code becomes more expensive. – PKlumpp Jun 13 '14 at 07:39
  • 1
    @blank Oh, by the way, when the exception is never thrown (When `Integer.parseInt()` receives `String` qualified as `Integer`) Using a `try{}` block DOES have better performance. But when the exception is thrown more than a dozen times, regex performance is drastically better. So it seems like this is more algorithm-ended, but preferably use regex anyway. :D – Unihedron Jun 13 '14 at 11:15
  • *if definitely* - this is untrue for null checks (or actually lack of), null deference can be handled by the hardware - even if the `if (x!=null)` is perfectly predicted by the hardware it still takes 1-2cycles. While you should not be catching NPE to deal with the case, exceptions are not so slow either - esp. when the compiler can prove the stack trace is unneeded. – bestsss Jun 18 '14 at 16:59
  • elaborate it @bestsss – jmj Jun 18 '14 at 17:00
  • Jigar, the edit box handles pressing `return` in pop-up context menus and cut off the answer – bestsss Jun 18 '14 at 17:03
10

Without even having to benchmark: Exception are ALWAYS way more expensive than programming defensively and using ifs as null-guard etc. Exceptions are always more expensive (several orders of magnitude), because the stack trace has to be generated.

Relevant SO question with benchmark: How slow are Java exceptions?

Community
  • 1
  • 1
hiergiltdiestfu
  • 2,339
  • 2
  • 25
  • 36
5

If emits a single branch. Throwing an exception "unrolls" the stack, which takes much longer.

Tripp Kinetics
  • 5,178
  • 2
  • 23
  • 37