問題タブ [exception]

いくつかのCOM オブジェクトを含むDLLがあります。場合によっては、このオブジェクトがクラッシュし、多数の 16 進情報とともに Windows イベント ログにエラー イベントが登録されます。このクラッシュが発生する理由はわかりません。

では、これらの COM オブジェクトの例外を追跡するにはどうすればよいでしょうか?

簡単な文字列暗号化が必要だったので、次のコードを作成しました（ここから多くの「インスピレーション」を得て）。

間違ったキーでデータを復号化すると、decryptStringのcs.Close（）行に「パディングが無効で削除できません」というCryptographicExceptionが発生することを除いて、コードは正常に機能しているように見えます。

サンプルコード：

私の質問は、これは予想されることですか？間違ったパスワードで復号化すると、例外ではなく、意味のない出力になると思っていたでしょう。

スレッドを再起動しようとすると、System.Threading.ThreadStateExceptionが発生することがあります。問題のコードは次のとおりです。

それで、2つの質問-これは物事を行う正しい方法ですか、そしてそれは、エラーの発生を防ぐ方法がありますか？

ユーザーが存在しないコントローラーを要求したときにスローされる例外をキャプチャして、404ページにリダイレクトできるようにしたいと思います。これどうやってするの？

たとえば、ユーザーが要求しますhttp://www.nosite.com/paeges/1（である必要があります /pages/）。例外画面ではなく404にリダイレクトされるようにするにはどうすればよいですか？

エラーを例外に変換する方法を見つけました。キャッチされない場合は適切に表示しますが、便利な方法でログに記録する方法がわかりません。それらを単にファイルに書き込むだけでは役に立ちませんよね？また、例外の原因がまだわからない場合、データベースにアクセスする危険がありますか?

ユーティリティにユーザーIDを与え、そのユーザーにメールを送信するコードがあります。

MailExceptionメールアドレスの問題、メールテンプレートの問題など、さまざまな理由でスローされる可能性があります。

私の質問はこれです：これらの例外のすべてに対して新しい例外タイプを作成してから個別に処理しますか、それとも1つのMailExceptionを作成してから例外に何か（説明テキストではなくコンピューターで読み取り可能なもの）を格納しますか？実際に起こったことに基づいて、さまざまなことを行います。

編集：明確にするために、例外はログなどではなく、コードがログにどのように反応するかに関係しています。メールの例を続けるために、メールを送信するときに、メールアドレスがないために失敗したり、有効なメールアドレスがないために失敗したり、失敗したりする可能性があるとします。

私のコードは、これらの問題のそれぞれに対して異なる反応を示したいと思います（主に、クライアントに返されるメッセージを変更しますが、実際のロジックも変更します）。

これらの問題のそれぞれに例外を実装するか、コードに問題の種類を区別させる内部的なもの（列挙型）を持つ1つの包括的な例外を用意するのが最善でしょうか。

現在、UIからASP.Netアプリを作成しています。私はWinformsにうんざりしていて、関心の分離がより優れたものが欲しかったので、MVPアーキテクチャを実装しています。

したがって、MVPを使用すると、プレゼンターはビューによって発生したイベントを処理します。ユーザーの作成に対処するために私が用意しているコードは次のとおりです。

組み込みの.Net検証コントロールを使用してメインフォームの検証を実行しましたが、データがサービスレイヤーの基準を十分に満たしていることを確認する必要があります。

次のサービスレイヤーメッセージが表示されるとしましょう。

• メールアカウントは既に存在します（失敗）
• 入力した参照ユーザーが存在しません（失敗）
• パスワードの長さがデータストアの許容長を超えています（失敗）
• メンバーが正常に作成されました（成功）

また、UIが予測できないより多くのルールがサービスレイヤーに含まれるとしましょう。

現在、計画どおりに進まなかった場合、サービスレイヤーに例外をスローさせています。それは十分な戦略ですか？このコードはあなたたちに臭いがしますか？このようなサービスレイヤーを作成した場合、このように使用するプレゼンターを作成する必要があることに悩まされますか？リターンコードは古すぎるように思われ、ブール値は十分な情報を提供しません。

OPではなく編集：OPによって回答として投稿されたフォローアップコメントにマージ

Cheekysoft、ServiceLayerExceptionの概念が好きです。予期しない例外のためのグローバル例外モジュールがすでにあります。これらすべてのカスタム例外を面倒にすると思いますか？基本の例外クラスをキャッチするのは少し臭いと思っていましたが、そこからどのように進行するのか正確にはわかりませんでした。

tgmdbm、ラムダ式の巧妙な使用が好きです！

フォローアップしてくれたCheekysoftに感謝します。したがって、例外が処理されない場合にユーザーに別のページ（私は主にWeb開発者）が表示されることを気にしないのであれば、それが戦略になると思います。

ただし、ユーザーがエラーの原因となったデータを送信したのと同じビューでエラーメッセージを返したい場合は、プレゼンターで例外をキャッチする必要がありますか？

PresenterがServiceLayerExceptionを処理したときのCreateUserViewは次のようになります。

この種のエラーの場合は、同じビューに報告すると便利です。

とにかく、私たちは今、私の最初の質問の範囲を超えていると思います。あなたが投稿したものをいじってみます。さらに詳細が必要な場合は、新しい質問を投稿します。

FXCopを使用していくつかのレガシーコードを分析しているときに、tryブロック内で一般的な例外エラーをキャッチするのは本当に悪いことであるか、特定の例外を探している必要があります。はがきに思いを馳せてください。

サーバーにリスニング ポートがあり、Java クラスとSocketインターフェイスを使用して接続しています。

次に をつかみ、 autoflush モードで をOutputStreamデコレートPrintWriterすると、私は笑います (リスニング ポートが閉じている場合を除く)。それから私は得る

プログラムの問題を検出できないようです-ソケットでメソッドを使用しようとしましたisConnected()が、接続が閉じられていることを認識していないようです。

次回ソケットに書き込もうとするときに問題を認識して、再接続して問題を報告できるようにしたいと思います。

アドバイスをお願いします。

皆さんありがとう

例外処理には 2 つのアプローチがあることを知っています。それらを見てみましょう。

1. 契約アプローチ。

   メソッドがメソッド ヘッダーで実行すると述べていることを実行しない場合、例外がスローされます。したがって、メソッドは操作を実行することを「約束」し、何らかの理由で失敗した場合は例外をスローします。

2. 例外的なアプローチ。

   本当に奇妙なことが起こった場合にのみ、例外をスローします。通常の制御フロー (If ステートメント) で状況を解決できる場合は、例外を使用しないでください。コントラクト アプローチの場合のように、制御フローに例外を使用しません。

さまざまなケースで両方のアプローチを使用してみましょう。

OrderProduct というメソッドを持つ Customer クラスがあります。

契約アプローチ:

例外的なアプローチ:

ここでは例外的なアプローチを好みます。なぜなら、顧客が宝くじに当選しなかったと仮定してお金を持っていないということは、真に例外的ではないからです。

しかし、これは私が契約スタイルを誤っている状況です。

優れた:

CreateCar というメソッドを呼び出すと、実行中のコードを数十行後に破壊する可能性のあるお粗末な null ポインターではなく、Car インスタンスが期待されます。したがって、私はこれよりも契約を好みます。

あなたはどちらのスタイルを使いますか？例外に対する最も一般的なアプローチは何だと思いますか?