1

expat パーサーに 3 つのハンドラーを登録しました: - start -end - text

そして、メイン プログラムから xml ファイルを読み取り、それをバッファリングして、XML_Parse API を呼び出します。このようなもの：

try {
if( ! XML_Parse (....))
{
   // throw user-defined expection here
}
catch(...)
{
}
} // end of try
catch(...)
{
 }

失敗時に XML_Parse が 0 を返す場合、if 内部から例外がスローされています。そしてインナーキャッチブロックに引っ掛かります。

これが私の質問です: 解析中にユーザー定義の例外がハンドラーのいずれかからスローされた場合、それは外側の catch でキャッチされますか?

はいの場合、実際には私のコードでは発生していません。代わりに、コアをダンプしており、スタックは、throw が std:terminate につながることを示しています。HANDLERS から例外をスローする前に何か他のことを実行する必要がありますか?

ありがとう。

4

3 に答える 3

0

try{/*stuff*/}ブロック内から例外をスローし、throwが深くネストされている場合、スタックは一致する外部catch(...)関数まで巻き戻されます。ハンドラーがヒープメモリを割り当てている場合は、明示的かつ慎重にshared_ptr<>使用または削除することにより、これに対処する必要があります。ハンドラーがブロック内にある場合、例外は通常どおりに動作するはずです。try

于 2011-10-27T13:27:38.833 に答える
0

これには細心の注意を払う必要があります。(私が取り組んでいたいくつかのコードで、追跡が非常に困難な問題が発生しました。) 私の場合、使用しなければならなかった expat ライブラリは、gcc で必要な例外フラグを使用してビルドされていませんでした。また、expat は (C++ ではなく) C であるため、例外が発生したときにアプリケーションが終了しただけでした。 .

ただし、適切な gcc フラグを使用して expat をビルドできれば、すべて問題ありません。(expat を再構築することはできなかったので、代わりに libxml2 を使用して DOM 解析に切り替えました)。

于 2011-10-27T13:45:10.227 に答える
0

との間に不一致がtryありcatchます: 各tryブロックの後に少なくとも 1 つのcatchブロックが続きますが、 は 1 つしかありませんtry。多分このように：

try
{
  // stuff before

  try
  {
    if (!parse())
    {
      // ...
    }
  }

  // further catch blocks?

  catch(...)
  {
    // may rethrow
  }

  // stuff after
}

匿名catch(...)は通常、あまり良い設計ではないことに注意してください。何を期待して処理できるかを知っているか、それをキャッチする必要がないかのどちらかです。匿名のキャッチが行う唯一の有用なことは、例外をログに記録して再スローすることです。

于 2011-10-27T12:43:08.447 に答える