Difference between Exceptions and if then in Java

Question

I have 2 examples:

void terminate(String x) {
     System.exit(0);
}

void x (long y) {
if(y == null) {
    terminate();
}
//code
}
.....
x(null); //Don't want that

This example seems to work. I want to make sure that long y is not null. I might do this instead:

void x (long y) throws NullPointerException {
//code
}
...
try {
x(null);
} catch (NullPointerException e) {
 e.printstacktrace();
}

What would the difference in performance be? In such example, it might not be visible, but in a complex program, would it matter? Should I get into practice of exceptions instead of if then?

Actually your code is already protecting you from `null`! A `long` can never be null. — eckes, Apr 14 '16 at 19:39
Dont worry about performance it does not matter in your case. (Technically the try/catch can be faster for non-null and slower for null cases. But it does depend on the pattern. So tyically you cannot predict one or the other. Performance should not be your main concern on how to structure code (unless you measured you had a problem in this place). — eckes, Apr 14 '16 at 19:41
Unclear what you wanted to ask. Use exceptions to threat errors (inside function calls), but still check for nulls if it makes sense — Exceptyon, Apr 14 '16 at 19:41
If you do not used System.exit() - which you should stay away from then your code basically boils down to the question how to tell the caller what was wrong (if it cares). And most likely the exception will be a leaner code. If not, use the if. — eckes, Apr 14 '16 at 19:44

Cephalopod · Accepted Answer · 2016-04-14T19:51:29.143

Use exceptions for exceptional circumstances, when things happen that youdid not expect and where nothing sensible can be done to recover.

Otherwise, use if-then and maybe return a status code.

In terms of performance, exceptions create a huge overhead compared to returns. Calling a method and catching an exception if it didn't work is verbose and annoying.

void myOperation() {
   step1();
   step2();
   step3();
}

In this example, exceptions are preferable for when any of the steps fails, the entire operation fails anyways, so I prefer not having to deal with any of this.

void myOperation(String number) {
    int n;
    try { 
        n = Integer.parse(number);
    } catch (NumberFormatException e) {
        n = DEFAULT;
    }
    doThings(n);
}

In this case, having to catch the exception is annoying because I kind of expect the string to be invalid and have a reasonable alternative. The exception makes the code slow and verbose.

I respectfully disagree that checking for an exception is necessarily verbose. It is worse to have to check every return to see if it is null. I would rather a method throw an exception than return a null object. The code is, IMHO, easier to read without a bunch of `if (obj == null) { //bail anyway }` constructs. — KevinO, Apr 14 '16 at 19:46

score 0 · Answer 2 · edited May 23 '17 at 10:28

What would the difference in performance be?

Version with exception definitely will works slower and will have overhead of processing exceptions, creating objects, filling stack traces and so on.

In such example, it might not be visible, but in a complex program, would it matter? Should I get into practice of exceptions instead of if then?

In complex programs none use this kind of processing possible null pointer exceptions, and it's actually anti-pattern in java, so if you whant be save with null you should you kind of not null check like if(x!=null) or assert.

Also I advice you read more about exceptions in java and differences between checked/unchecked exceptions and so on.

PS here is good topic about null checks.

Difference between Exceptions and if then in Java

2 Answers2