2016-05-01 7 views
20

Gibt es einen Unterschied zwischen zwei Methoden?Zurück von der Methode, im "try" -Block oder nach dem "catch" -Block?

Welches ist vorzuziehen und warum?

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;  
} 
+2

Ich mag das zweite Schnipsel besser, da ich es sauberer (und klarer) finde. Ich denke nicht, dass es einen Leistungsunterschied macht. – Eran

+1

Ich mag die erste besser, wegen dem, was passieren wird, wenn Sie sich entscheiden, die Ausnahme lokal zu behandeln, anstatt sie erneut zu werfen. – njzk2

Antwort

23

Betrachten Sie diese Fälle, in denen Sie keinen konstanten Ausdruck Rückkehr:

Fall 1:

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

Fall 2:

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

Ich würde es vorziehen, die erste. Die zweite ist ausführlicher und könnte beim Debuggen zu Verwirrung führen.

Wenn test() falsch null zurückgibt, und Sie sehen toReturn zu null initialisiert wird, könnte man denken, das Problem in test() ist (vor allem, wenn test() nicht nur ein einfaches Beispiel, wie das ist).

Auch wenn es nur null zurückgeben kann, wenn doSomethingnull zurückgibt. Aber das ist auf den ersten Blick schwer zu erkennen.


Sie könnten dann argumentieren, dass aus Gründen der Konsistenz, es die erste Form besser zu immer verwenden ist.

4

Nein gibt es keinen Unterschied zwischen den beiden Verfahren. In beiden Fällen wird der wahre Wert zurückgegeben, indem der Programmablauf wieder aufgenommen wird, sobald eine Ausnahme behandelt wird. Auf Catch wird nur zugegriffen, wenn eine Ausnahme auftritt.

-5

Es gibt keinen Unterschied, aber das erste Prg1 ist schneller als das Prg2.

+0

Ein Beweis dafür? –

+0

mit diesem Code können Sie es beweisen: \t long startTime, endTime, Dauer; \t \t startTime = System.nanoTime(); \t \t test2(); // oder test1() \t \t endTime = System.nanoTime(); – ABBOne

+2

das ist kein guter Weg zum Benchmarking einer Anwendung –

3

Es gibt keinen funktionalen Unterschied. Beide Programme verhalten sich gleich. Es ist nur eine Frage des Codierungsstils und des persönlichen Geschmacks.

Als eine gute Methode ist es besser, eine einzelne Return-Anweisung pro Methode zu haben - am Ende der Methode statt dazwischen. Im Falle von langen Code-Blöcken macht dieser Stil den Code in Zukunft lesbarer und wartbarer, wenn der (ursprüngliche Autor oder jemand anderes) Änderungen am Code vornehmen muss.

Daher wird die erste vom Standpunkt der guten Praxis als besser angesehen.

+3

Könnte bitte aufhören, diese alte Weisheit zu recyceln, die nicht länger relevant ist stackoverflow.com/questions/36707/should-a -function-have-only-one-return-Anweisung –

2

Ich nehme an, das ist eine allgemeine Frage. Ansonsten könnte ich andere Aspekte Ihrer Methode (n) kommentieren.

Ich denke in dem Fall oder kleine Methoden wie diese ist es nicht wirklich wichtig. Die Methode ist kurz genug, um sofort zu verstehen, was passiert, was damit zusammenhängt usw.

Bei längeren Methoden ist der Ablauf im ersten Beispiel jedoch wesentlich einfacher. Meiner Meinung nach. Es enthält verwandte Codes und verwandte Szenarien. Wenn Sie die Methode lesen, wird der normale Ausführungsfluss nicht durch den Block catch unterbrochen, wodurch er deutlicher und "flüssiger" wird.

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

Aber ich verallgemeinere dies nicht für alle Methoden; Es geht nur um den Kontext.

Verwandte Themen