intriijが到達不能ステートメントにリターンを追加する理由を

Question

私のIDEは、catchブロックの後にhello（）メソッドで "retrun"ステートメントを追加すると不平を言っています。そのリターンステートメントに到達できないのですか？なぜ私はそれを含めるべきですか？

import java.sql.SQLException; 

public class Test { 
    public static void main(String[] args) { 
     hello(); 
    } 


    public static boolean hello() { 

     try{ 
      hello2(); 
     } catch(SQLException e){ 
      handleException(); 
     } 
     return false; 
    } 

    public static String hello2() throws SQLException { 
     throw new SQLException(""); 
    } 

    public static void handleException(){ 
     throw new RuntimeException(); 
    } 
} 

Answer 1

リターンステートメントに到達できませんか？

ステートメントが到達可能であると判断するためにJLSが指定するルールによれば、return false;ステートメントに到達できます。 （詳細はJLS 14.21を参照してください。）

このルールでは、別のメソッドの動作を考慮していません。メソッドが実際にどのように実装されていても、いずれのメソッド呼び出しもに戻ることを前提にしています。

このメソッドが別のコンパイル単位にある場合は、JLSの前提が不可欠です。 （呼び出されたメソッドが呼び出されたメソッドを再コンパイルせずに変更され再コンパイルされる場合を考えてください）

メソッドのロジックが複雑な場合にも必須です。メソッドが終了できるかどうかをコンパイラが確かめることは不可能な場合があります。 c.f. Halting Problem。コンパイラが任意のメソッド呼び出しが返るかどうかを判断する能力に依存するJavaプログラムの「正しさ」にとっては、悪いことです。簡単な解決策（JLSで採用されています）は、コンパイラが到達可能性チェックの目的でそれをやろうとするべきではないということです。

Answer 2

hello()をコンパイルするとき、それはこれらのメソッドは常に例外をスローすることを知らないので、コンパイラは、hello2()とhandleException()のコードを解析しません。したがって、hello()にreturnステートメントが必要です。これは、try-catchブロックの後のコードがコンパイラーが理解できる限り到達可能であるためです。

あなたが直接代わりに例外をスローするメソッドを呼び出すの例外をスローするためにあなたの方法を変更した場合は、return文は必要ありません。

public static boolean hello() { 
    try{ 
     throw new SQLException(""); 
    } catch(SQLException e){ 
     throw new RuntimeException(); 
    } 
} 

Answer 3

try-catchは、単に問題を試み、解決するための解決策を行うと言いますそれとさらにコードの実行に移る

try{ 
      hello2(); // exception 
     } catch(SQLException e){ // may occur , handle here 
      handleException(); 
     } 
     // normal execution from here 

     return false; 

プラスあなたはhello2()はすでにcatchブロックによって処理された例外をスローので、コンパイラは、私のようなあらゆる可能性を考えてf hello2()は常に例外をスローしないかもしれません（またはコンパイラはNetegrityに行かず、メソッドが動的なコードのために明示的ではない場合にのみ値を返します）、そのケースのreturn文を要求しています