問題タブ [throwable]

効果的なJava（第2版）の項目4では、非インスタンス化を強制するためのプライベートコンストラクターの使用について説明しています。この本のコードサンプルは次のとおりです。

しかし、AssertionError投げるのは正しいことではないようです。「アサート」されるものはありません。これは、APIがAssertionErrorの使用を定義する方法です。

Throwableこの状況で一般的に見られる違いはありますか？Exception通常、メッセージとともに将軍を投げるだけですか？それともException、このための習慣を書くのが一般的ですか？

それはかなり些細なことですが、何よりも私はスタイルと標準の観点からそれについて興味があります。

与えられた:ThrowableはExceptionのスーパークラスです。

独自の「例外」の記述に関するテキストを読むと、ブロックで使用されている例とThrowable、catchブロックで使用されている他のテキストが表示new Exception() されcatchます。それぞれをいつ使用する必要があるかについての説明はまだ見ていません。

私の質問はこれです、いつ使用する必要Throwableがあり、いつ使用する必要new Exception()がありますか?

catchorelseブロック 内で次のいずれかを使用します。

また

Javaを何年もやっているので、C++を追跡していません。最終的に、言語定義のC ++例外処理に句が追加されましたか？

Javaのtry/finalを模倣する好ましいイディオムはありますか？

また、JavaのThrowableクラスのように、C ++には、スローされる可能性のあるすべての例外に対する究極のスーパータイプがないことも気になります。

私は書くことができます：

補遺編集：

投票数が最も多かった、つまりデストラクタを使用してクリーンアップを行う回答を受け入れることになりました。もちろん、私自身のコメントから、私がそれに完全に同意しないことは明らかです。ただし、C ++はそれ自体であるため、私が念頭に置いているアプリケーションの取り組みでは、多かれ少なかれ、一般的なコミュニティの慣習に従うように努めます。テンプレートクラスを使用して、クラスデストラクタがまだないリソース（つまり、Cライブラリリソース）をラップし、デストラクタセマンティクスを付与します。

新しい補遺編集：

うーん、最終的には閉鎖機能ではなく、おそらく？ScopeGuardアプローチ（以下の回答の1つを参照）と組み合わせたクロージャーは、任意のアクションとクリーンアップコードの外部スコープコンテキストへのアクセスを使用してクリーンアップを実行する方法になります。クリーンアップは、リソースが開かれているときにクリーンアップブロックを提供するRubyプログラミングで見られるイディオム方式で実行できます。C ++ではクロージャ機能が検討されていませんか？

基本的な Java とさまざまなタイプの Throwable についてもっと学ぼうとしています。誰かが例外とエラーの違いを教えてもらえますか?

たとえば、一般的なアイテムをディスパッチし、エラーから回復する必要があるディスパッチャー キューを作成する場合など、Throwable をキャッチする必要がある場合があります (ディスパッチャーは、キャッチされたすべての例外をログに記録しますが、黙って実行し、他のアイテムで実行を継続します)。

私が考えることができるベスト プラクティスの 1 つは、例外が InterruptedException の場合は常に再スローすることです。

別の提案（回答ではなくコメントからのもの）は、常にThreadDeathを再スローすることです

他のベストプラクティスはありますか?

Exception.fillInStackTraceは、Exceptionオブジェクトまたは派生Exceptionオブジェクトを返す必要があると思います。以下の2つの機能を考慮すると、

1. は最初の関数でをexception handlerキャッチできませんでした。new Throwable()f()
2. は、2番目の関数でexception handlerをキャッチできます。e.fillInstackTrace()g()
3. しかし、2番目の関数g()はまだする必要がありthrows Throwableます。捕まえることができたので、これは本当に奇妙e.fillInstackTrace()です。

だから私の質問は、Exception.fillInStackTraceがそのような奇妙な構文を開発する代わりに例外または例外派生を返さないのはなぜですか？

編集：私の質問
を明確にするために：私が「奇妙な構文」とはどういう意味ですか

1. Exception.fillInStackTrace()参照を返すためThrowable、参照を受け取る例外ハンドラーは例外Exceptionをキャッチできないはずです。javaは暗黙的なダウンキャストを許可しないため、のようなものにする必要がありますreturn (Exception)e.fillInstackTrace()。
2. Exception参照を受け取る例外ハンドラーが例外を処理できるように設計されているため、メソッドが例外をスローThrowableすることをマークする必要はありませんが、Javaコンパイラーはそうするように強制します。g()Throwable

ありがとう。

知っている

完全なstackTraceなどを作成するため、かなり大きなオーバーヘッドがあります。

同じ問題を提示しますか？この動作は継承されていますか、それとも、Throwable をスローするとオーバーヘッドが小さくなりますか?

EDITアナリストの観点から、間違ったパスワードを挿入するユーザーは、プログラムの通常の実行順序の例外です
。だから私が持っている場合：

アナリストの観点からは、UserNotValidException をスローすることは正しいように思えます。あなたのコードがかなり良い抽象化を持っている場合、
返すnullか、単に間違っているように聞こえます。0これを実際にコードで実装できるかどうか、または理論に任せる必要があるかどうかを知りたかっただけです。

プログラミング視点の例外とアナリスト視点の例外には大きな違いがあります。

注: 非常に単純でばかげた例を示しましたが、これは私の場合とは異なります。
注 2: 戻るnullのが普通のことであることはわかっていますが、適切に抽象化されたオブジェクト指向のコードが必要であり、個人的にはこれに害はないと思います。

APIドキュメントには、異常な動作を示すThrowableサブクラスErrorをキャッチしないと記載されています。エラーと例外の分離は、どのサブクラスをキャッチする必要があり、どのサブクラスをキャッチするべきでないかをプログラマーに伝えることを意味しますか？それともそれ以上のものがありますか？

時々、私は見る

そして時折

違いはなんですか？

Java がジェネリックをサポートしないThrowableのはなぜですか?

型の消去が特定のことを複雑にしていることは理解していますが、明らかに Java はすでに多くのことを行っています。それをさらに押し上げて、ジェネリックを許可Throwableし、潜在的な問題を包括的にコンパイル時にチェックしてみませんか?

型消去の引数はかなり弱いように感じます。現在、次のことはできません。

もちろん、それなしでやっていけます。同じブロック内でcatch Bouncy<T1>とを実行できるようにする必要があるとは言いませんが、厳密なコンパイル時の強制可能なルール (現在のジェネリックの動作とほとんど同じです) を使用してばらばらなコンテキストでそれらを使用すると、そうではありませんか?実行可能ですか？Bouncy<T2>try