問題タブ [throws]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
3 に答える
17391 参照

java - Python : Java は Python で同等のものをスローします

言語を比較しようとするのではなく、単なる知識として、

throwsPythonでjavaキーワード/機能に相当する方法はありますか?

または、静的時に任意のメソッドによってスローされたチェック済み例外を認識する方法は?

または、例外処理の責任を渡す(連鎖する)?

ジャワ:

パイソン:

0 投票する
1 に答える
81 参照

java - 処理された例外の throws ステートメント -- Java

次のコードがあるとします。

someMethodはIOExceptionをスローし、他のチェック例外はスローせず、その例外自体を処理します。

正確には

その宣言で持ち込んでいますか?私が知っていることから、someMethod()を呼び出すメソッドがそのIOException自体を処理できるようになっています。

ここで他に何か起こっていますか?

0 投票する
3 に答える
1039 参照

java - 派生クラスで throws 宣言を省略する

次のインターフェースを検討してください。

および次の実装:

インターフェイスthrows IOExceptionで指定された署名の一部を省略したことに注意してください。Generatorそれでも、コンパイラ エラーやコンパイラ警告はなく、@Override注釈も文句を言いません。

これが意図したとおりに機能していることは承知しています。ただし、この背後にある意図を知りたいと思います。私のメソッドが実際に をスローしない場合は、スローしないIOExceptionだけで問題ありません。署名から削除する必要はありません。しかし、 のメソッド シグネチャからそれを削除するとEmptyStringGenerator、このクラスの現在および将来のすべてのサブクラスが、インターフェイスで実際に指定されている例外をスローする可能性を放棄することになります。

私には、これは実際には何のメリットももたらさない機能のように思えますが (2、3 のキーストロークを節約することは別として、これはまったくメリットではありません)、実際に使用するとひどい間違いになる可能性があります。

私の質問は、事実上、次のとおりthrowsです。派生クラスで例外を省略することのポイントは何ですか? この可能性が解決する問題は何ですか? なぜこれが許可されているのですか?

アップデート

「しかし、それのどこに害があるのですか?」と尋ねる人のために、私のコメントの1つからの私の例を次に示します. ちなみに、それはまさに私が今扱っているものなので、大げさではありません。

プログラマー A はインターフェイス I を指定します。プログラマー B は実装クラス X を記述しますが、スローを追加するのを忘れます。ここでは警告すら出されていないので、彼も決して気づきません。プログラマー C は、クラス X から継承する実装クラス Y を作成します。彼は、スローするつもりなので、そこにスローを配置することも特に望んでいます。しかし、インターフェイスにはそれが規定されていますが、B の見落としにより、彼はもはやそうすることが許可されていません。ここでその例外を使用することは事実上許可されていません。それはかなり大きな害です。特にクラスXがあなたの管理下にない場合。

0 投票する
2 に答える
2079 参照

java - IllegalArgumentException をキャッチする必要がないのはなぜですか?

クラスをキャッチまたは宣言する必要IllegalArgumentExceptionがないのに、他の例外をキャッチまたは宣言する必要があるのはなぜだろうか(例: )。java.net.MalformedURLException

Errors はキャッチされることを意図していないため、宣言する必要がないことはわかっています。

キャッチする必要のない新しい例外を宣言したいと思います。

0 投票する
4 に答える
39171 参照

java - メソッド シグネチャのスローと Java のスロー ステートメントの違い

メソッドシグネチャのスローとJavaのスローステートメントの違いを明確にしようとしています。メソッドシグネチャのスローは次のとおりです。

スローステートメントは次のとおりです。

私の理解ではthrows、メソッド署名は、メソッドがそのような例外をスローする可能性があるという通知です。throwステートメントは、状況に応じて作成されたオブジェクトを実際にスローするものです。その意味で、メソッド内にthrowステートメントが存在する場合、メソッド シグネチャ内の throw は常に表示される必要があります

ただし、次のコードはそうしていないようです。コードはライブラリからのものです。私の質問は、なぜそれが起こっているのですか?概念を間違って理解していますか?

このコードは、java.util.linkedList からのコピーです。@著者 ジョシュ・ブロック

答えの更新:

更新 1 : 上記のコードは次と同じですか?

更新 2 : チェックされた例外の場合。署名に「スロー」が必要ですか? はい。