問題タブ [exception-safety]

呼び出しはf()例外セーフですか?

auto_new()つまり、 2 つの関数がインラインである場合、1 番目と 2 番目の関数呼び出しのアトミック性に違いはありますか?

InitOnceExecuteOnce WinAPI 関数に例外の安全性の問題があります。コールバック関数から例外がスローされるたびにデッドロックが発生します。コールバックは、データが正常に初期化されたかどうかを呼び出し元に伝えるブール値のフラグを返しますが、false を返すと、例外を再スローできなくなります。これは良くありません。私はこの方法で問題を解決しようとしました。

関数から例外をキャッチするたびに、構造体をもう一度初期化して例外を再スローするため、フラグが初期状態であるため、他のスレッドは初期化されていないデータを検出します。ただし、最初のスレッドが例外をキャッチしてフラグを再度初期化する前に、他のスレッドが同期オブジェクトを待機し始めたため、デッドロックが発生することもあります。その問題の解決策はありますか？

前もって感謝します。

Exception Safety Guarateesについて説明し、 Strong Guaranteeを提供すると思われる例を考案しました。

簡単な (C++0x)-これがどのように使用されるかの例:

LT要素を変更しないと仮定しますが、スローされる可能性があります。コードが提供するものであると仮定するのは正しいですか

• 強力な例外安全保証
• Exception Neutralであり、 wrt toLT

Java の標準クラスの例外の安全性に関する詳細を取得する方法はありますか? 主に C++ と C# を使用しており、Java の例外仕様について混乱しているため、例外の適切な処理方法を理解する必要があります。

より具体的に考えてみましょうServerSocket。オブジェクトが構築されるとすぐに、着信接続のリッスンを開始します。次に、accept()接続を受け入れるために使用する必要があります (誰かが接続しようとした場合)。

以前に でサーバー ソケットを構成したことがある場合は、指定された時間内に誰も接続を試みなかったため、スローさsetSoTimeout()れる変更があります。それは問題ありません。サーバー ソケットはまだ使用できるので、もう一度呼び出すだけです。accept()SocketTimeoutExceptionaccept()

しかし、投げるSocketTimeoutExceptionことができるのはそれだけではありません。accept()他のすべての例外はどういう意味ですか? accept()への呼び出しを2 つの catch 句でラップする場合: forSocketTimeoutExceptionとIOException、句に入った後でも関連するインスタンスを安全に使用できますか?ServerSocketIOException

Java全体とServerSocket固有の両方の回答をいただければ幸いです。

(copy-and-swap イディオムを使用して) クラスを作成するときの一般的なガイドラインは、スローしないスワップ メンバー関数を提供することです。( Effective C++、第 3 版、項目 25およびその他のリソース)

ただし、クラスがスワップ操作を提供しないサードパーティ クラス メンバーを使用しているために、nothrow 保証を提供できない場合はどうなりますか?

CString スワップを非スローにすることはできないため、スワップが失敗する可能性は低いです。

注: まれなサード パーティ クラスでは、スマート ptr (pimpl) を使用することもできますが、 -

注: CString は良い例です。彼の正気 (?) の誰も、pimpl (smart ptr) を介して CString のような概念的に単純でユビキタスなクラスのすべてのメンバーを保持し始めることはありません。 CString を変更して完全にノースロー スワップを許可する (短期から中期) チャンスはありません。

それで、あなたがそれを助けることができないなら、スワップメンバー関数をスローする可能性があっても大丈夫ですか? （または、この難問を回避する方法を知っていますか？）

編集:そして:強力な保証ではない場合、基本的な保証を提供するために、スロースワップメンバーをコピーアンドスワップイディオムで使用できますか?

クラスの特定のインスタンスが null にならないようにするにはどうすればよいですか? 誰かが私に Debug.Assert() を使用するように言いましたが、そうすることで、コードがデバッグモードで機能することだけを保証しますが、リリースでも is-never-null 条件を保証したいと考えています。

たとえば、過去に次のようなコードを書きました。

ただし、instance1 が null の場合、これは例外をスローします。このような間違いを犯したり、将来的にそのような例外を生成したりすることは避けたいと思います。

ありがとう、

問題を説明する以下の特定の例を参照してください。

サーバーからの応答に基づいてユーザーを認証する方法があります。メソッドは次のとおりです。

このメソッドを呼び出すために、私は使用します

私はまた、とりわけ、このプロパティを持っています

何が起こったのかというと、_authenticationResult が 1 回 null で、プロパティ AuthResult が「null.auth」の試行時に nullref をスローしたことです。どうすれば(おそらくCheckUser()メソッド内で)nullを返さないことを確認できますか?

アプリをデバッグしたとき、それは起こりませんでした。しかし本番環境では、サーバーがタイムアウトしたときに、メソッドが null を返すことがありました。

ありがとう、

重複の可能性:
同期句内で例外をスローすることの副作用?

synchronized例外セーフかどうか疑問に思っていますか? たとえば、同期ブロック内でキャッチされない例外が発生した場合、ロックは解除されますか?

私は、例外安全なコードを実現するために、次のようなコードを書いていることに気づきました。

Objective-Cで従うべき他のより簡潔なパターンはありますか？

私は単純なメモリ アリーナ アロケーターを作成していて、例外の安全性に関する小さな問題に直面しています。状況は、それ自体がアロケーターを呼び出すオブジェクトを割り当てる場合です。メモリ プールの目的は、一度に多数のオブジェクトを割り当て、プールが破棄されたときにそれらをすべて削除することです。

しかし、これは複数回使用するとかなり厄介になります。内部割り当てがクリーンアップされた場合、後で使用できます。プールの定義は、有効期間が終了するまでオブジェクトを削除しないため、悪い仮定ではありません。検討：

しかし、内側の割り当てがクリーンアップされない場合、外側の割り当てもクリーンアップできません。これは、メモリ アリーナがハードウェア スタックのように線形に割り当てるため、メモリ リークが発生するためです。したがって、オブジェクトを早期に破棄してセマンティクスに違反するか、メモリ リークを起こします。

この問題を解決する方法について何か提案はありますか?

いくつかの標準コンテナの例外安全性を確認するためのオンラインリファレンスを見つけようとしています。

の場合 std::vector、push_back呼び出しの前の状態を保持しますか？ベクトルにはまだすべてのオブジェクトが有効であると思います（デストラクタは呼び出されません）。std::vectorpush_backが例外をスローした後、どのような保証が提供されstd::bad_allocますか？