問題タブ [exception]

私は両方の状況にありました：

• カスタム例外の作成が多すぎる
• 一般的な例外クラスの使用が多すぎます

どちらの場合も、プロジェクトは問題なく開始されましたが、すぐに維持 (およびリファクタリング) のオーバーヘッドになりました。

独自の例外クラスの作成に関するベスト プラクティスは何ですか?

Java (またはチェック済みの例外を持つ他の言語) で、独自の例外クラスを作成する場合、チェックするかチェックしないかをどのように決定しますか?

私の本能は、チェックされた例外は、呼び出し元が生産的な方法で回復できる可能性がある場合に呼び出されると言うのですが、チェックされていない例外は回復できない場合に多くなりますが、他の人の考えに興味があります。

C++ プログラムから例外情報を抽出するツールを探していました。私が探している最も必要な機能: 関数からスローされる可能性のあるすべての例外 (その関数から再帰的に呼び出されるすべての関数を含む) を知りたいです。

特にエラーと例外を文書化するのは非常に難しい (そして、最新の状態に保つには多大な労力が必要) と常に思っていました。しかし、それを自動化する方法があれば、非常に役に立ちます。

Windows と Visual Studio 用のツールが望ましいですが、必須ではありません。いつでも回避できます。

Visual Studio のインストールに問題があります。例外が発生すると、スタック トレースの行番号が常に正しくありません。私のコードベースには、各メソッドの最後の行へのポイントが常にあります。同時に、デバッガーでプログラムをトレースしているときは問題ありません。PDB はどうなっているのですか?

いいえ、各メソッドで例外を再スローしていません。

スタック トレースの各行には、対応するメソッドの最後の行がありますが、途中でステートメントによって例外がスローされました。

次のような単純な Web サービス操作があります。

次に、Web サービスを使用して操作を呼び出すクライアント アプリケーションがあります。明らかに例外がスローされます:-)

私のキャッチブロックでは、実際の例外のメッセージを抽出してコードで使用したいと考えています。キャッチされた例外は aSoapExceptionです。これは問題ありませんが、Messageプロパティは次のようになります...

...そして、InnerExceptionですnull。

私がやりたいのは、 (私のサンプルのテキスト)のMessageプロパティを抽出することです。誰でもそれを手伝ってもらえますか? 回避できる場合は、 のプロパティの解析を提案しないでください。InnerExceptionHelloWorldExceptionMessageSoapException

たとえば、ログに記録して次のリクエストにスキップする、ユーザーにメッセージを表示して次のイベントを処理するなど、すべての失敗を同じ方法で処理したい場合は、未チェックの例外で問題ありません。私のシステムの高レベルで一般的な例外タイプをキャッチし、すべてを同じ方法で処理する必要があります。

しかし、特定の問題から回復したいのですが、チェックされていない例外を使用してそれにアプローチする最善の方法がわかりません。これが具体的な例です。

Struts2 と Hibernate を使用して構築された Web アプリケーションがあるとします。私の「アクション」に例外が発生した場合は、それをログに記録し、かなりの謝罪をユーザーに表示します。しかし、私の Web アプリケーションの機能の 1 つは、一意のユーザー名を必要とする新しいユーザー アカウントを作成することです。ユーザーが既に存在する名前を選択すると、Hibernate はorg.hibernate.exception.ConstraintViolationExceptionシステムの内部で (未チェックの例外) をスローします。この特定の問題から回復したいのですが、ユーザーに別のユーザー名を選択するように依頼するのではなく、同じ「問題をログに記録しましたが、今のところ問題が発生しています」というメッセージを表示するのではありません。

考慮すべきいくつかの点を次に示します。

1. 同時にアカウントを作成する人がたくさんいます。名前が存在するかどうかを確認する「SELECT」と、存在しない場合の「INSERT」の間でユーザーテーブル全体をロックしたくありません。リレーショナル データベースの場合、これを回避するためのいくつかのトリックがあるかもしれませんが、私が本当に興味を持っているのは、基本的な競合状態のために例外の事前チェックが機能しない一般的なケースです。ファイルシステムでのファイルの検索などにも同じことが当てはまります。
2. "Inc." の技術コラムを読むことによって誘導されたドライブバイ管理に対する私の CTO の傾向を考えると、Hibernate を破棄して Kodo などを使用できるように、永続化メカニズムの周りに間接的なレイヤーが必要です。永続化コードのレイヤー。実際のところ、私のシステムにはそのような抽象化のレイヤーがいくつかあります。チェックされていない例外にもかかわらず、それらがリークするのを防ぐにはどうすればよいですか?
3. チェック例外の宣言された弱点の 1 つは、呼び出し元のメソッドがそれらをスローすることを宣言するか、それらをキャッチして処理することにより、スタック上のすべての呼び出しでそれらを「処理」する必要があることです。それらを処理することは、多くの場合、抽象化のレベルに適したタイプの別のチェック済み例外でそれらをラップすることを意味します。したがって、たとえば、チェック例外の土地では、UserRegistry のファイル システム ベースの実装は をキャッチIOExceptionし、データベースの実装は をキャッチしますが、どちらも下層の実装を隠すSQLExceptionをスローします。UserNotFoundException未チェックの例外を利用して、実装の詳細を漏らすことなく、各レイヤーでこのラップの負担を軽減するにはどうすればよいですか?

私はC＃用のANTLRパーサーライブラリを使用してプロジェクトに取り組んでいます。私はいくつかのテキストを解析するための文法を構築しました、そしてそれはうまくいきます。ただし、パーサーが不正または予期しないトークンに遭遇すると、多くの例外の1つをスローします。問題は、場合によっては（すべてではない）、try / catchブロックがそれをキャッチせず、代わりに未処理の例外として実行を停止することです。

私にとっての問題は、この問題を他の場所では再現できないことですが、完全なコードでしか再現できません。呼び出しスタックは、例外がtry / catch（Exception）ブロック内で確実に発生することを示しています。私が考えることができる唯一のことは、私のコードと例外をスローするコードの間にいくつかのANTLRアセンブリ呼び出しが発生し、このライブラリではデバッグが有効になっていないため、ステップスルーできないことです。デバッグ不可能なアセンブリが例外バブリングを禁止するのだろうか？呼び出しスタックは次のようになります。外部アセンブリ呼び出しはAntlr.Runtimeにあります：

Parse（）の一番下の呼び出しからのコードスニペットは次のようになります。

私にとって、catch（Exception）句は、あらゆる例外をキャプチャする必要がありました。そうしない理由はありますか？

更新： Reflectorを使用して外部アセンブリをトレースしましたが、スレッド化の形跡はまったく見つかりませんでした。アセンブリは、ANTLRで生成されたコードのランタイムユーティリティクラスのようです。スローされる例外はTimeDefLexer.mTokens（）メソッドからのものであり、そのタイプはNoViableAltExceptionであり、RecognitionException->Exceptionから派生します。この例外は、レクサーがストリーム内の次のトークンを理解できない場合にスローされます。つまり、入力が無効です。この例外は発生することが想定されていますが、try/catchブロックによってキャッチされているはずです。

また、ParserExceptionの再スローは、この状況とはまったく関係ありません。これは、解析中に例外を受け取り、自分のParserExceptionに変換する抽象化レイヤーです。私が経験している例外処理の問題は、そのコード行に到達することはありません。実際、「新しいParserExceptionをスローする」部分をコメントアウトしても、同じ結果が得られました。

もう1つ、問題の元のtry / catchブロックを変更して、代わりにNoViableAltExceptionをキャッチし、継承の混乱を排除しました。私はまだ同じ結果を受け取りました。

ある人は、デバッグモードでVSが処理された例外をキャッチするのに過度にアクティブになることがあると提案しましたが、この問題はリリースモードでも発生します。

男、私はまだ困惑しています！以前は触れていませんでしたが、VS 2008を実行していて、コードはすべて3.5です。外部アセンブリは2.0です。また、私のコードのいくつかは、2.0アセンブリのクラスをサブクラス化します。バージョンの不一致がこの問題を引き起こす可能性がありますか？

更新2： .NET3.5コードの関連部分を.NET2.0プロジェクトに移植し、同じシナリオを複製することで、.NETバージョンの競合を解消することができました。.NET 2.0で一貫して実行しているときに、同じ未処理の例外を複製することができました。

ANTLRが最近3.1をリリースしたことを知りました。そこで、3.0.1からアップグレードして再試行しました。生成されたコードは少しリファクタリングされていることがわかりましたが、同じ未処理の例外が私のテストケースで発生します。

更新3：このシナリオを簡略化されたVS2008プロジェクト に複製しました。プロジェクトをダウンロードして、自分で調べてみてください。私はすべての素晴らしい提案を適用しましたが、この障害をまだ克服することができていません。

回避策を見つけることができる場合は、調査結果を共有してください。再度、感謝します！

ありがとうございますが、VS2008は未処理の例外で自動的に中断します。また、[デバッグ]->[例外]ダイアログがありません。スローされるNoViableAltExceptionは完全に意図されており、ユーザーコードによってキャッチされるように設計されています。期待どおりにキャッチされないため、未処理の例外としてプログラムの実行が予期せず停止します。

スローされる例外はExceptionから派生したものであり、ANTLRでマルチスレッドが実行されることはありません。

MS VC++ で答えを探しています。

大規模な C++ アプリケーションをデバッグする場合、残念ながら C++ 例外が非常に広範囲に使用されます。実際に必要な時間よりも少し遅れて例外をキャッチすることがあります。

擬似コードの例:

デバッグ時にブレークポイントで例外をキャッチできます。FunctionA()しかし、例外がor FunctionB()、または他の関数で発生したかどうかを追跡することはできません。(広範な例外の使用と上記の例の巨大なバージョンを想定しています)。

私の問題に対する 1 つの解決策は、コール スタックを決定し、例外コンストラクターで(つまり、キャッチされる前に) 保存することです。しかし、これには、この基本例外クラスからすべての例外を派生させる必要があります。また、多くのコードが必要になり、プログラムの速度が低下する可能性があります。

作業が少なくて済む簡単な方法はありますか? 大規模なコード ベースを変更する必要はありませんか?

他の言語でこの問題に対するより良い解決策はありますか?

IDisposableを実装するオブジェクトがある場合、最近、usingブロックをますます活用しようとしていますが、私が理解していないことの1つは、通常のtry / catch/finallyのように例外をキャッチする方法です...私を正しい方向に向けるためのコードサンプルはありますか？

編集：回答を読んだ後、質問が変更されました。それは「.NET2.0でusingブロックで例外をスローする方法」でした。しかし、私は実際に、usingブロック内でこれらの例外をキャッチする方法を探していました。

自分のキャッチングブロックをusingブロック内で転がす方法の詳細を探しています。

編集：私が避けたかったのは、@Blairが示したように使用ブロック内でtry/ catch/finallyを使用する必要があることです。しかし、おそらくこれは問題ではありません...

編集：@ブレア、これはまさに私が探していたものです、詳細な返信に感謝します！

を使用assert()してアサーションが失敗すると、assert()が呼び出さabort()れ、実行中のプログラムが突然終了します。私の製品コードではそれを行う余裕はありません。実行時にアサートする方法はありますが、失敗したアサーションをキャッチして、それらを適切に処理する機会がありますか?