例外処理とロギングのベストプラクティス
はじめに システム開発において例外処理は重要なポイントですが、あまりに軽視されているのが現状ではないでしょうか。本稿では、これまでの著者の開発経験の中から培った汎用的な手法を説明します。 この記事は「美しい設計」ではなく「現実的な設計」、現場に適用できる「できるだけ手間の少なく、汎用的な設計」を目指しています。 対象読者 J2EE開発者・アーキテクト。特に業務システムの開発現場の方が対象です。 必要な環境 概念の説明が中心ですので、開発環境は必要ありません。 エラーの分類 実装時に考慮すべきエラーは2つに大別できます。 想定内でトランザクションの実行開始前にチェックするエラー。主に入力エラー。 異常な状態としてトランザクションの続行が不可能なエラー（例外）。 前者については、例外を使うべきではありません。入力チェックエラーを表現するには、ステータスコードを使うべきです。理由は次のとおりです
例外のベスト プラクティス - .NET
アプリケーションの信頼性には、適切な例外処理が不可欠です。 予期される例外を意図的に処理して、アプリがクラッシュするのを防ぐことができます。 ただし、クラッシュするアプリは、定義されていない動作を示すアプリよりも信頼性が高く、診断が容易です。 ここでは、例外の処理と作成のためのベスト プラクティスについて説明します。 例外処理 次のベスト プラクティスは、例外の処理方法に関するものです。 try/catch/finally ブロックを使用して、エラーから回復するか、リソースを解放する 例外を回避する方法で一般的な状態を処理する キャンセル例外と非同期例外をキャッチする 例外を回避できるようにクラスを設計する 例外が原因でメソッドが完了しない場合は状態を復元する 例外をキャプチャして適切に再スローする try/catch/finally ブロックを使用し、エラーから回復させるか、リソースを解
例外設計の話
例外設計の話。 こんな指針がいいのかなー 2013 夏 ver. 例外の目的とは？ 「例外をキャッチする主な目的は、エラーの原因を取り除いて、回復すること」 via http://dobon.net/vb/dotnet/beginner/exceptionhandling.html .NET の「例外のデザインのガイドライン」にもこう書いてある。 特定の例外が特定のコンテキストでスローされる理由を把握できている場合は、その例外をキャッチするようにしてください。 回復可能な例外だけをキャッチする必要があります。たとえば、存在しないファイルを開こうとした場合に発生する FileNotFoundException は、アプリケーションで処理できる例外です。それは、アプリケーションがユーザーに問題を知らせ、ユーザーが別のファイル名を指定したり、ファイルを作成したりできるようにすることが可能だからで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
例外は基本投げずに処理し，できないならRuntimeExceptionを投げるべし - 超ウィザード級ハッカーのたのしみ
