問題タブ [throw]

C++ では、例外指定子を使用して、関数が例外をスローするかどうかを指定できます。例えば：

次の理由から、実際にそれらを使用することに疑問があります。

1. コンパイラは厳密な方法で例外指定子を実際に強制するわけではないため、メリットは大きくありません。理想的には、コンパイル エラーを取得したいと考えています。
2. 関数が例外指定子に違反した場合、標準的な動作はプログラムを終了することだと思います。
3. VS.Net では、throw(X) を throw(...) として扱うため、標準への準拠は強くありません。

例外指定子を使用する必要があると思いますか?
「はい」または「いいえ」で答え、その理由を説明してください。

ここで質問した例外をスローするコードを書いているときに、メッセージの最後に来て、句読点で一時停止しました。これまでにスローしたほぼすべての例外メッセージには、おそらく ! が含まれていることに気付きました。どこか。

例外メッセージを書くとき、あなたはどのようなトーンをとりますか? ログを調べたときに、特定のスタイルのメッセージが実際に他よりも役立つことがわかりましたか?

例外は遅いと言う人をよく見かけますが、その証拠は見当たりません。したがって、そうであるかどうかを尋ねる代わりに、例外が舞台裏でどのように機能するかを尋ねます。これにより、例外をいつ使用するか、例外が遅いかどうかを判断できます。

私が知っていることから、例外は、リターンの束を何度も実行するのと同じですが、リターンのたびに、別のリターンを実行する必要があるか、停止する必要があるかどうかもチェックします。復帰を停止するタイミングをどのように確認しますか? 例外のタイプとスタックの場所を保持する2番目のスタックがあると思いますが、そこに到達するまで戻ります。また、この 2 番目のスタックに触れるのは、スローと各 try/catch のみであると推測しています。リターンコードを使用して同様の動作を実装する AFAICT には、同じ時間がかかります。しかし、これはあくまでも推測なので、実際にどうなるか知りたいです。

例外は実際にどのように機能しますか?

これは、標準 C++ で Final のような動作を実装する良い方法ですか? (特別なポインタなし)

1. オブジェクトによって例外がスローされない -> NoException -> オブジェクトがクリーンアップされる
2. オブジェクトによってスローされた例外 -> 処理済み -> NoException -> オブジェクトのクリーンアップ
3. オブジェクトによってスローされた例外 -> スローされた -> 例外 -> オブジェクトがクリーンアップされた -> スローされた

重複の可能性:
アサートまたは例外による契約テストによる設計?

アサートの代わりに例外を使用することを決定する際に従うべき経験則はありますか (またはその逆)。現在、実行時にユーザー側で発生すると思われるもの (ソケットまたはファイル エラーなど) の場合にのみスローします。私が使用する他のほとんどすべてはアサートします。

また、アサートをスローする場合、スローするのに適した標準オブジェクトは何ですか? 私の記憶が正しければ がありますがstd::logic_error、それは投げるのに適したオブジェクトではありませんか? 不足しているファイルまたは予期しない入力 (フロントエンド アプリではなくコマンド ラインからなど) に対して何をスローしますか?

Java で例外をスローすることについて質問があります。これは、私の側からの一種の誤解であるように思われます。これについては、自分で明確にしたいと思います。

例外コードを処理する2つの基本的な方法は次のとおりです。

1.) 「throw new ...」を使用して try ブロックで例外をスローし、catch ブロックですぐにキャッチする - いわゆる try-throw-catch メカニズム。

2.) 「throw new ...」を使用してメソッドで例外をスローし、メソッドのヘッダーで、このメソッドが「throws ...」を使用して例外をスローする可能性があることを宣言する - いわゆるパスザバック。

最近、「例外をスローして同じメソッドでキャッチしても意味がない」という記事を読んで、私の理解が間違っているのか、これを書いた人に何かあったのかと思いました。他に念頭に置いてください。例外を処理する最初の方法はまさにこれ (try-throw-catch メカニズム) ではありませんか? つまり、例外をスローし、同じメソッドでキャッチします。あるメソッドで例外をスローし、別のメソッドで例外をキャッチする方が良い方法であると読みましたが、これは 1 つの (おそらくより良い) 方法です。他の方法も合法で正しいですね。

これについてコメントをいただけますか？どうもありがとうございました。

情報が不足しているため、文字列をスローしてはいけないと聞きました。キャッチするとは思わない例外をキャッチします。例外をスローするための良い方法は何ですか? 基本例外クラスを継承しますか? 例外は多いですか、それとも少ないですか。MyExceptionClass& または const MyExceptionClass& を実行しますか? など。また、デストラクタで例外をスローしてはならないことも知っています

契約による設計と、いつ例外をスローするかを理解していることを付け加えます。例外をスローする方法を尋ねています。

例外処理でのthrowの使用について誰か説明してもらえますか？例外をスローするとどうなりますか？

C++ 関数から可能な例外スローを宣言する利点は何ですか? 言い換えれば、キーワードを追加するとthrow()実際に何ができるのでしょうか?

void do_something() throw();のような関数宣言は、関数から例外が発生しないことを保証する必要があることを読みましたdo_something()。ただし、これは 内で呼び出される関数には当てはまらないようdo_something()で、弱い保証になります。

この言語機能の有用性 (および最適な使用例) について概説してください。

コンストラクターから例外をスローすることについて同僚と議論していて、フィードバックが欲しいと思いました。

設計の観点から、コンストラクターから例外をスローしても大丈夫ですか？

POSIXミューテックスをクラスでラップしているとしましょう。次のようになります。

私の質問は、これがそれを行うための標準的な方法ですか？呼び出しが失敗した場合pthread mutex_init、ミューテックスオブジェクトは使用できないため、例外をスローすると、ミューテックスが作成されなくなります。

むしろ、Mutexクラスのメンバー関数initを作成し、そのpthread mutex_init中で呼び出して、の戻り値に基づいてブール値を返す必要がありpthread mutex_initますか？このようにして、このような低レベルのオブジェクトに例外を使用する必要はありません。