問題タブ [nested-exceptions]

したがって、C++ を使用して例外をネストする方法std::nested_exceptionは次のとおりです。

しかし、この手法では、例外をネストしたいすべてのレベルで明示的な try/catch ブロックを使用します。これは控えめに言っても見苦しいものです。

Jon Kalbが「責任の取得は初期化である」と拡張した RAII は、明示的な try/catch ブロックを使用する代わりに、例外を処理するためのはるかにクリーンな方法です。RAII では、明示的な try/catch ブロックは、ユーザーにエラー メッセージを表示するなど、最終的に例外を処理するためにのみ主に使用されます。

上記のコードを見ると、入るfoo()ことは、例外を報告しstd::runtime_error("foo failed")、nested_exception 内に詳細をネストする責任を伴うと見なすことができるように思えます。RAII を使用してこの責任を負うことができれば、コードはよりきれいに見えます。

ここで RAII 構文を使用して、明示的な try/catch ブロックを置き換える方法はありますか?

これを行うには、デストラクタが呼び出されたときに、デストラクタの呼び出しが例外によるものかどうかを確認し、そうであればその例外をネストし、巻き戻しが正常に続行されるように、ネストされた新しい例外をスローする型が必要です。それは次のようになります。

ただしstd::throw_with_nested()、「現在処理されている例外」がアクティブである必要があります。つまり、catch ブロックのコンテキスト内以外では機能しません。したがって、次のようなものが必要です。

残念ながら、私の知る限りrethrow_uncaught_excpetion()、C++ で定義されているようなものはありません。

ユーザーが提供した電子メールIDに電子メールを送信しようとしていますが、以下になっています:

ここでの問題は、MailSendException をキャッチし、有効な emailId を提供してくださいという意味のあるエラー メッセージをクライアントに送信できることです。この例外は、他のさまざまな理由で発生する可能性があります。

私の問題は、SMTPAddressFailedException をキャッチしたいということですが、残念ながらこの場合はネストされた例外であり、Spring によってスローされる実際の例外は非常に一般的な MailSendException です。提案してください

このコードNotFoundExceptionが発生するとメインブロックの例外が発生しますが、発生させたいのですがNotFoundException、どうすれば対処できますか?

デストラクタから例外をスローする際の主な問題は、デストラクタが呼び出された瞬間に別の例外が「飛行中」( std::uncaught_exception() == true) である可能性があるため、その場合に何をすべきかが明らかではないことです。古い例外を新しい例外で「上書き」することは、この状況を処理する可能な方法の 1 つです。しかし、そのような場合はstd::terminate(または別のstd::terminate_handler) を呼び出さなければならないことが決定されました。

C++11 では、std::nested_exceptionクラスを介してネストされた例外機能が導入されました。この機能は、上記の問題を解決するために使用できます。古い (キャッチされていない) 例外を新しい例外にネストするだけで (またはその逆?)、ネストされた例外をスローすることができます。しかし、このアイデアは使用されませんでした。std::terminateC++11 および C++14 では、このような状況でも呼び出されます。

だから質問。ネストされた例外を含むアイデアは考慮されましたか? 問題はありますか？C++17で状況が変わるんじゃないの？

malloc()私は、ランダムにreturnを作成することにより、特にメモリ不足の状態で何が起こるかについて、クラスをテストする強力な例外保証を行ってきましたnullptr。ネストされた例外を使用します。

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

std::throw_with_nested()呼び出すことになったstd::terminate()：

これは、標準に従って意図された動作ですか? std::bad_alloc個人的には、ネストされた例外の割り当てに失敗した場合は、古い例外を上書きするか、スローするだけでよいように感じます。