21

Is there any difference between following two methods?

Which one is preferable and why?

Prg1:

public static boolean test() throws Exception {
    try {
        doSomething();
        return true;
    } catch (Exception e) {
        throw new Exception("No!");
    }    
}

Prg2:

public static boolean test() throws Exception {
    try {
        doSomething();
    } catch (Exception e) {
        throw new Exception("No!");
    }
    return true;    
}
Jonathan Eustace
  • 2,469
  • 12
  • 31
  • 54
EbraHim
  • 2,279
  • 2
  • 16
  • 28
  • 2
    I like the second snippet better, since I find it cleaner (and clearer). I don't think it makes a difference performance wise. – Eran May 01 '16 at 10:27
  • 1
    I like the first one better, because of what will happen if you decide to handle the exception locally instead of re-throwing it. – njzk2 May 01 '16 at 19:20

4 Answers4

24

Consider these cases where you're not returning a constant expression:

Case 1:

public static Val test() throws Exception {
    try {
        return doSomething();
    } catch (Exception e) {
        throw new Exception("No!");
    }
    // Unreachable code goes here
}

Case 2:

public static Val test() throws Exception {
    Val toReturn = null;
    try {             
        toReturn = doSomething();
    } catch (Exception e) {
        throw new Exception("No!");
    }
    return toReturn;
}

I would prefer the first one. The second is more verbose and might cause some confusion when debugging.

If test() incorrectly returns null, and you see toReturn being initialized to null, you might think the problem is in test() (especially when test() is not just a simple example like this).

Even though it can only return null if doSomething returns null. But that might be hard to see at a glance.


You could then argue that, for consistency's sake, it's better to always use the first form.

Jorn Vernee
  • 31,735
  • 4
  • 76
  • 93
4

Nope there is no difference between both the methods. It will return true value in both the cases effectively by resuming the flow of the program as soon an and exception is handled. Catch will be accessed only when an exception occurs.

rvp_15
  • 74
  • 3
2

I'm assuming this is a general question. Otherwise I might comment on other aspects of your method(s).

I think in the case or small methods like these it doesn't really matter. The method is short enough to understand immediately what's going on, what's related to what etc.

However, in the case of longer methods the flow is much easier to follow in the first example. In my opinion. It keeps together related code and related scenarios. When you're reading the method, the normal execution flow is not broken by the catch block, making it more obvious and "fluent".

public static boolean test() throws Exception {
    try {
        doSomething();
        return true;
    } catch (Exception e) {
        throw new Exception("No!");
    }    
}

But I won't generalize this for all methods; it's all about the context.

async
  • 1,537
  • 11
  • 28
-5

There is no difference, but the first Prg1 is faster than the Prg2.

ABBOne
  • 13
  • 1
  • Any proof of that? – Po-ta-toe May 01 '16 at 11:05
  • by using this code you can proof it: long startTime,endTime,duration; startTime = System.nanoTime(); test2(); // or test1() endTime = System.nanoTime(); – ABBOne May 01 '16 at 12:28
  • For a start you're altering the program. – Po-ta-toe May 01 '16 at 14:18
  • 2
    by adding metrics inline with your code you are actually affecting what your code does. Your program now has to run steps it shouldn't have to. This may alter the way the compiler generates the IL – Po-ta-toe May 01 '16 at 14:45