5

カスタム例外をスローするメソッドのコレクションを含む別の JAR ライブラリがあります。次に例を示します。

public String methodName() throws CustomException {
    // code here
}

次に、JAR をクラスパスに追加し、ソース コードの try ステートメント内でライブラリ メソッドを参照します。

try {
    DemoClass demoClass = new DemoClass ();
    demoClass.methodName() // this should throw a CustomException if something occurs
} catch (CustomException e) {
    // something here
}

上記のコード スニペットは、次のコンパイル エラーを返し続けます。

対応する try ステートメントの本体で CustomException がスローされることはありません

メソッドがローカル コンテキスト (JAR にパッケージ化されていない) にある場合、コードは機能します。私の質問は、JAR ライブラリからカスタム例外を「スロー」することは可能ですか?

4

3 に答える 3

2

"class" は予約済みのキーワードであるため、使用しないでください。

try {
    MyClass myClass = new MyClass();
    myClass.methodName() // this should throw a CustomException if something occurs
} catch (CustomException e) {
    // something here
}

また、「MyClass」と「CustomException」を同じ jar からインポートしていること、およびスニペットと「MyClass」が同じパッケージから「CustomException」をインポートしていることを確認してください。

于 2012-09-05T10:14:42.777 に答える
1

クラスが jar にあるかローカル コンテキストにあるかは問題ではなく、常に例外をスローできます。クラスを使用していて、意図したメソッドを呼び出しているかどうかを確認する必要があります。他のクラスや同じ名前の他のメソッドではありません。

私の予感ParseExceptionは、どちらが両方java.text.ParseExceptionにorg.apache.commons.cli.ParseExceptionあり、demoClass.methodName()実際に前者をスローすると、後者をコードにインポートしてキャッチしようとするようなものであり、それがコンパイラーの不満です。CustomException が存在し、正しい場所をキャッチしようとしているすべての場所を確認することができます。

于 2012-09-05T10:14:22.810 に答える
0

問題は、それCustomExceptionがチェックされた例外であることですが、コンパイラーは、その例外をスローすると宣言さDemoClass.methodName()れていないバージョンを認識しています。次に、コンパイラは、メソッドのシグネチャが例外のスローを許可していないため、スローできないと推測します。

そのチェック済み例外をキャッチできるようにする場合は、throwsコンパイル対象のクラスのメソッド宣言の句に例外 (またはスーパークラス) を含める必要があります。

MyClass と customException が同じ JAR からインポートされていません。これが問題ですか?

それ自体ではありません。

ただし、実際には、2 つの JAR に関連するクラスまたはインターフェイスの 2 つの異なる (互換性のない) バージョンがあると思われます。それは間違いでしょう。コンパイルできたとしても、署名の競合が原因でクラスローダーの問題が発生する可能性が高くなります。

于 2012-09-05T10:59:12.993 に答える