問題タブ [throwable]
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.
java - プライベートユーティリティクラスコンストラクターで使用するのに適したThrowableは何ですか?
効果的なJava(第2版)の項目4では、非インスタンス化を強制するためのプライベートコンストラクターの使用について説明しています。この本のコードサンプルは次のとおりです。
しかし、AssertionError
投げるのは正しいことではないようです。「アサート」されるものはありません。これは、APIがAssertionErrorの使用を定義する方法です。
Throwable
この状況で一般的に見られる違いはありますか?Exception
通常、メッセージとともに将軍を投げるだけですか?それともException
、このための習慣を書くのが一般的ですか?
それはかなり些細なことですが、何よりも私はスタイルと標準の観点からそれについて興味があります。
java - 新しい例外の代わりにスロー可能を使用する必要があるのはいつですか?
与えられた:Throwable
はException
のスーパークラスです。
独自の「例外」の記述に関するテキストを読むと、ブロックで使用されている例とThrowable
、catch
ブロックで使用されている他のテキストが表示new Exception()
されcatch
ます。それぞれをいつ使用する必要があるかについての説明はまだ見ていません。
私の質問はこれです、いつ使用する必要Throwable
があり、いつ使用する必要new Exception()
がありますか?
catch
orelse
ブロック 内で次のいずれかを使用します。
また
c++ - C++でJavaのtry/finalを模倣するための好ましいイディオムはありますか?
Javaを何年もやっているので、C++を追跡していません。最終的に、言語定義のC ++例外処理に句が追加されましたか?
Javaのtry/finalを模倣する好ましいイディオムはありますか?
また、JavaのThrowableクラスのように、C ++には、スローされる可能性のあるすべての例外に対する究極のスーパータイプがないことも気になります。
私は書くことができます:
補遺編集:
投票数が最も多かった、つまりデストラクタを使用してクリーンアップを行う回答を受け入れることになりました。もちろん、私自身のコメントから、私がそれに完全に同意しないことは明らかです。ただし、C ++はそれ自体であるため、私が念頭に置いているアプリケーションの取り組みでは、多かれ少なかれ、一般的なコミュニティの慣習に従うように努めます。テンプレートクラスを使用して、クラスデストラクタがまだないリソース(つまり、Cライブラリリソース)をラップし、デストラクタセマンティクスを付与します。
新しい補遺編集:
うーん、最終的には閉鎖機能ではなく、おそらく?ScopeGuardアプローチ(以下の回答の1つを参照)と組み合わせたクロージャーは、任意のアクションとクリーンアップコードの外部スコープコンテキストへのアクセスを使用してクリーンアップを実行する方法になります。クリーンアップは、リソースが開かれているときにクリーンアップブロックを提供するRubyプログラミングで見られるイディオム方式で実行できます。C ++ではクロージャ機能が検討されていませんか?
java - 例外とエラーの違い
基本的な Java とさまざまなタイプの Throwable についてもっと学ぼうとしています。誰かが例外とエラーの違いを教えてもらえますか?
java - Java で Throwable をキャッチするためのベスト プラクティス
たとえば、一般的なアイテムをディスパッチし、エラーから回復する必要があるディスパッチャー キューを作成する場合など、Throwable をキャッチする必要がある場合があります (ディスパッチャーは、キャッチされたすべての例外をログに記録しますが、黙って実行し、他のアイテムで実行を継続します)。
私が考えることができるベスト プラクティスの 1 つは、例外が InterruptedException の場合は常に再スローすることです。
別の提案(回答ではなくコメントからのもの)は、常にThreadDeathを再スローすることです
他のベストプラクティスはありますか?
java - Exception.fillInStackTraceがThrowableを返すのはなぜですか?
Exception.fillInStackTraceは、Exceptionオブジェクトまたは派生Exceptionオブジェクトを返す必要があると思います。以下の2つの機能を考慮すると、
- は最初の関数でを
exception handler
キャッチできませんでした。new Throwable()
f()
- は、2番目の関数で
exception handler
をキャッチできます。e.fillInstackTrace()
g()
- しかし、2番目の関数
g()
はまだする必要がありthrows Throwable
ます。捕まえることができたので、これは本当に奇妙e.fillInstackTrace()
です。
だから私の質問は、Exception.fillInStackTraceがそのような奇妙な構文を開発する代わりに例外または例外派生を返さないのはなぜですか?
編集:私の質問
を明確にするために:私が「奇妙な構文」とはどういう意味ですか
Exception.fillInStackTrace()
参照を返すためThrowable
、参照を受け取る例外ハンドラーは例外Exception
をキャッチできないはずです。javaは暗黙的なダウンキャストを許可しないため、のようなものにする必要がありますreturn (Exception)e.fillInstackTrace()
。Exception
参照を受け取る例外ハンドラーが例外を処理できるように設計されているため、メソッドが例外をスローThrowable
することをマークする必要はありませんが、Javaコンパイラーはそうするように強制します。g()
Throwable
ありがとう。
java - Javaで例外とスロー可能に関連するオーバーヘッド
知っている
完全なstackTraceなどを作成するため、かなり大きなオーバーヘッドがあります。
同じ問題を提示しますか?この動作は継承されていますか、それとも、Throwable をスローするとオーバーヘッドが小さくなりますか?
EDITアナリストの観点から、間違ったパスワードを挿入するユーザーは、プログラムの通常の実行順序の例外です
。だから私が持っている場合:
アナリストの観点からは、UserNotValidException をスローすることは正しいように思えます。あなたのコードがかなり良い抽象化を持っている場合、
返すnull
か、単に間違っているように聞こえます。0
これを実際にコードで実装できるかどうか、または理論に任せる必要があるかどうかを知りたかっただけです。
プログラミング視点の例外とアナリスト視点の例外には大きな違いがあります。
注: 非常に単純でばかげた例を示しましたが、これは私の場合とは異なります。
注 2: 戻るnull
のが普通のことであることはわかっていますが、適切に抽象化されたオブジェクト指向のコードが必要であり、個人的にはこれに害はないと思います。
java - Throwableのどのサブクラスをキャッチする必要があり、どのサブクラスをキャッチするべきではありませんか?
APIドキュメントには、異常な動作を示すThrowableサブクラスErrorをキャッチしないと記載されています。エラーと例外の分離は、どのサブクラスをキャッチする必要があり、どのサブクラスをキャッチするべきでないかをプログラマーに伝えることを意味しますか?それともそれ以上のものがありますか?
java - trycatchでThrowableとExceptionを使用する場合の違い
時々、私は見る
そして時折
違いはなんですか?
java - Java が一般的な Throwables をサポートしないのはなぜですか?
Java がジェネリックをサポートしないThrowable
のはなぜですか?
型の消去が特定のことを複雑にしていることは理解していますが、明らかに Java はすでに多くのことを行っています。それをさらに押し上げて、ジェネリックを許可Throwable
し、潜在的な問題を包括的にコンパイル時にチェックしてみませんか?
型消去の引数はかなり弱いように感じます。現在、次のことはできません。
もちろん、それなしでやっていけます。同じブロック内でcatch Bouncy<T1>
とを実行できるようにする必要があるとは言いませんが、厳密なコンパイル時の強制可能なルール (現在のジェネリックの動作とほとんど同じです) を使用してばらばらなコンテキストでそれらを使用すると、そうではありませんか?実行可能ですか?Bouncy<T2>
try