問題タブ [custom-exceptions]

エラー処理を渡すために、コードで例外を使用することにしました。新しい例外を作成するたびに、コードを複製していることに気づきました。これらのクラスは特別なものではなく、メッセージのみが含まれていました。しかし、私はそれらを渡すときに型安全性に依存するようになりました。コンストラクターを再実装せずに新しい例外クラスタイプを提供する方法はありますか？

上記のコードは、定義したい例外の種類ごとに何度も複製されます。

これは私が取り組んできた学校の課題です。私は家庭教師と行ったり来たりして、彼はこれで私を助けてくれましたが、ここで明らかに欠けているものがあります. 問題のプログラムは引数「-f filename.txt」を取り、そのファイル名には次のようなもののリストがあります

プログラムはこれらの名前を取得し、リフレクションを使用してクラスを作成し、生成されたクラス (FansOn など) の action() メソッドを呼び出します。クラスごとにスレッドを作成してからスレッドを開始すると、「ファンがオンになっています」などのメッセージが生成されます。PowerOut と WindowMalfunction の 2 つのイベントで、カスタム例外 ControllerException をスローします。この例外は、呼び出されたオブジェクトを取得し、後で調べるためにGreenhouseControls呼び出されたファイルにシリアル化する必要があります。dump.out私が抱えている問題は、自分の電話をかけることができることですghcSuspend()例外呼び出しの直後にすべてのイベントを中断するメソッド。実際、この時点で、私のプログラムは大規模なスタック オーバーフローの問題を生成するだけです。ここにコード全体を投稿する必要があるかどうかはわかりません。他の誰かが私のコースを受講してコードの大部分を手渡されることを明らかに望んでいないため、皆さんに私の問題を理解してもらうために何を投稿すればよいかわかりません.

したがって、私のmain()方法では、GreenhouseControlsgc というオブジェクトを作成します。GreenhouseControls は、メイン クラス ファイルの名前です。最終的に、カスタム例外でこの gc オブジェクトが必要になります。これは、events.class ファイルで定義およびキャッチされます。

助けてくれてありがとう。

除数が 1 の場合、このコードは期待どおりの結果を生成しません。ExceptOne の基本クラスが呼び出されず、ExceptOne のハイパーリンクが表示されません。何が足りないの?!

コンソール出力は次のとおりです。

除数を入力してください
1
WriteLine exception 1...
WriteLine exception 2...
base ctor2
http : // exc2.com
Writeline in finally

このメソッドをテストするために Mockito ベースの JUnit メソッドを作成するにはどうすればよいadduser()ですか? 書いてみましたが、例外が処理されないというエラーメッセージで失敗しています。エラーは次の場合に表示されます。

addUser()ビジネスクラスのメソッドが例外をキャッチせず、再スローが行われないと仮定します。

テストケース方法：

ここのテスト クラスでは、属性を使用してサービス レイヤー クラスをモックし、@Mockそれを注入しています。

テスト ケースで例外シナリオを処理する方法を教えてください。

下にあるすべてのアイテムをバインドしたいとしましょう

を除外する

私は考えることができます

また：

より良いものは何ですか？

Web アプリのサービス層に JSR303 JavaBean Validation を実装しました (この記事によると)。ここで、すべての検証例外 (javax.validation.ConstraintViolationException など) をカスタム例外に変換したいと考えています。

サービス層で例外がスローされるたびに呼び出されるアスペクトを作成しました。

しかし、サービスが ConstraintViolationException で検証に失敗すると、例外変換の側面はトリガーされません。これは、検証例外自体がアスペクトによってトリガーされるためだと思われます。

アスペクトを正しい順序でチェーンするにはどうすればよいですか? 最初に ValidateAspect、続いて ExceptionConversionAspect?

同様のことが以前に尋ねられたことは知っていますが、それはこの問題に関する私の疑問を取り除くものではありません.

すべてのページの Page_Load メソッドと、データベースに接続するメソッドを呼び出す他のすべてのメソッドについて、コードを try catch ステートメント内に配置します。

エラーの種類ごとにカスタム例外を使用するのは賢明ですか?

• データベースにグループが見つからない場合 (上記のコードのように);
• グループが存在する場合。
• グループを更新できない場合。
• グループがメンバーの最大数 (5) に達したとき。
• 等。;

それとも、このエラー処理の方法を制限するのが最善ですか? 理由と時期はわかっていますが、いつ多すぎるか、どこで線引きをしなければならないかはわかりません。

フォローアップの質問です。グループに参加できる人数に制限があります。この制限は、コードでいつこれを強制するのですか? ページのコード ビハインド クラスで? それとも、データベースに接続するときですか? または両方？

問題は次のとおりです。EJB が次の例外をスローします (glassfish ログから):

そして、例外スタックのクライアント側 (一番下) には、次のように表示されます。

もちろん、ブラウザーでは、null ポインター例外があったことを示す一般的な 500 例外エラーが発生します。

「com.extremelatitudesoftware.els_commons.exceptions.LoginPreviouslyConfirmedException」を検出し、「おっと、これは既に確認済みです!」のようなカスタム エラー ページが必要です。

これが行われるように、クライアント/JSFレイヤーが例外を正しく「見る」ようにするために、誰かが私を正しい方向に向けることができますか?

これが問題の使用例です
。EJB 層に、ユーザーが以前にログイン アカウントを確認したかどうかを確認するメソッドがあります。そうでない場合は、リクエストを処理して新しいアカウントを確認します。彼らが古い電子メールに戻って「うーん、それをもう一度クリックしましょう」と言った場合、バックエンドはそれを検出し、JSF/クライアント層によって取得されることを意図して例外をスローし、ユーザーに通知しますアカウントがすでに確認されていること。

サンプルコードの追加:

条件をチェックし、必要に応じて例外をスローするメソッド。ほとんどの場合、これは発生しないため、誰かがアカウントを確認するたびに不必要な呼び出しを行う代わりに、このメカニズムを使用したいと考えています.

カスタム例外:

これは、JSF 層の ManagedBean にあります。次の方法で呼び出されます: preRenderView

ログには次のように表示されます。

次に、いくつかトレースします。

BalusC の提案に従って、ManagedBean のコードを次のように変更しました。

これは web.xml にあります

次のカスタム例外ハンドラーを作成しました。

そして、このクラスとそのメソッドを使用して、システムによって生成されたすべての例外とエラーを次のように処理することを示しました。

また、画面にエラーが表示されないようにし、すべてのエラーを報告するように指示しました。

私の質問は今です-例外やエラーをキャッチするために、try {} catch（）{}ステートメントを使用する必要がありますか？上記はおそらく防弾ではないことを私は知っていますが、キャッチされていないすべての例外とエラーを処理することにより、try/catchステートメントなしでこれまでのところ機能しているようです。

また、カスタム例外ハンドラーを使用して、try {} catch（つまり、パフォーマンス/セキュリティなど）を介してこれを行うのではなく、キャッチされなかったすべての例外をキャッチさせることによる不利な点はありますか？

ServiceException、ConnectionException、InvalidDataException の 3 種類のカスタム Web サービス障害をスローする Web サービスを使用しています。

これらの catch ブロックに加えて、Spring のランタイム例外である RemoteAccessException の catch ブロックも入れました。

上記のカスタム例外をテストしているときに、これら 3 種類の例外すべてがそれぞれの catch ブロックでキャッチされていないことがわかりました。代わりに、RemoteAccessException である最後の catch ブロックですべてがキャッチされます。タイプ org.springframework.remoting.jaxws.JaxWsSoapFaultException の SOAP エラーの例外オブジェクトのデバッグ中に、サービスが正しいエラーをスローしていることがわかりました。

私の懸念は、これらの障害が独自の catch ブロックに分類されない理由です。サービス自体は、サービス呼び出しを行うときにこれらの例外を処理するように指示します。

プロキシ Java クライアントを介してサービスにヒットすると、障害はそれぞれのブロックに正しく分類されます。POJO に問題があった場合は、この場合も機能しないはずです。ただし、この場合 (Java プロキシ クライアントを介してヒットした場合) は機能しているため、POJO では問題ありません。

spring-2.5.6.jar を使用しています。