コンテキストを持つ例外とネストされた例外の長所と短所は何ですか?
Java のバックグラウンドがない、または Java のバックグラウンドを知らない開発者として、オープン ソース プロジェクトの例外処理を更新する可能性のある機会に出くわしましたが、私が行う変更が有益であることを確認したいと考えています。
問題のプロジェクトはddlutilsです。現在、org.apache.commons.lang.exception を使用しています。
「以前の Java バージョンの場合に、JDK 1.4 スタイルのネストされた例外機能を提供します。」
Commons Langの現在のバージョン(執筆時点では 3.1) は、次のように述べている org.apache.commons.lang3.exception を使用しています。
「コンテキストを持つ例外の概念が含まれています。つまり、そのような例外にはキーと値のマップが含まれます。これにより、呼び出しプロセスに有用な形式で例外時に貴重な状態情報を渡す簡単な方法が提供されます。」
これについて議論する場合、約 10 年前にリリースされた JDK1.4 に注意する必要があります。例外チェーンを発明しました。これは、単に原因例外を取るコンストラクターがあることを意味します。そして、それらすべての優れた複合スタック トレースが出力されます。JDK1.4 より前は、そのような実装が JDK に多数存在し、それらは単一の一貫したソリューションに統合されていました。Commons lang が行ったことは、いくつかの類似した基本クラスを提供して、この考え方を古い JDK に適用することでした。しかし、多くのことが起こったので：
したがって、「以前の JDK 1.4」バージョンに興味を持っている人はもういません。
一方、この例外とコンテキストの問題は、JDK バージョンとは何の関係もありません。これも例外の基本クラスですが、物事を入れるための Map があります。通常、これは追加フィールドを持つ特別な例外タイプによって実装されます。これは型安全で、素晴らしく、きれいです。すべての例外についてマップを持つということは、このマップに何が含まれるかを決して知らないことを意味します。これが提供する利点は考えられません。したがって、それを使用する本当に優れた計画がない場合は、お勧めしません。