はてなブログ | 無料ブログを作成しよう超絶品！死ぬまでに一度は食べてほしい煮込み10選 ああ。いかにもインターネット！みたいなタイトルをつけてしまった。 「超絶品！死ぬまでに一度は食べてほしい煮込み10選」て。読んでほしすぎて大仰な形容詞をつけて数字を入れて読み手の注意を引くタイトル、もうネット記事まるだしである。 でも、わかってほしい。…
例外処理とロギングのベストプラクティス
はじめに システム開発において例外処理は重要なポイントですが、あまりに軽視されているのが現状ではないでしょうか。本稿では、これまでの著者の開発経験の中から培った汎用的な手法を説明します。 この記事は「美しい設計」ではなく「現実的な設計」、現場に適用できる「できるだけ手間の少なく、汎用的な設計」を目指しています。 対象読者 J2EE開発者・アーキテクト。特に業務システムの開発現場の方が対象です。 必要な環境 概念の説明が中心ですので、開発環境は必要ありません。 エラーの分類 実装時に考慮すべきエラーは2つに大別できます。 想定内でトランザクションの実行開始前にチェックするエラー。主に入力エラー。 異常な状態としてトランザクションの続行が不可能なエラー（例外）。 前者については、例外を使うべきではありません。入力チェックエラーを表現するには、ステータスコードを使うべきです。理由は次のとおりです
cohakim's blog » [CakePHP]業務システム用にエラーハンドリングを実装するまとめ
概要 rails でいう rescue_from。 各コントローラで発生し処理されなかった例外を、 AppController で一括で補足して独自の例外処理を行うためのメモ。 ポイント エラーハンドリングの方針を決める 例外ハンドラをオーバーライドして独自の例外処理を定義できるようにする データベースへの問い合わせに失敗した場合、例外を投げてログにエラーメッセージを記録する プロダクションモードで例外ハンドラが正常に動作しない対策を行う エラーハンドリングの方針を決める 基本的に復帰できない例外をハンドリングするために使用します。（必要であるなら）エラーメッセージをログに記録し、汎用的なエラー画面を出力するというのが主な機能です。 画面に出力するエラーメッセージは、小規模な業務システムを想定し、以下のようなポリシーにします。 生のエラーメッセージを出さない。 復帰できないエラーであること
「他の例外クラスを継承しただけの例外クラスを作らない」に不同意の理由 - Diary Blog of Dary
オブジェクト倶楽部、コーディング規約の会の「C# コーディング標準」の駄目なところ - ぐるぐる～ これは多分、中身が空っぽな例外クラスを大量生産してるんだと予想。 中身がない例外クラスを作る目的としては、クラス名で例外の具体的な状況が表したいというのが大きいと思う。 でも、そういうのはフィールドに持たせれば十分な場合も多いので、あまり例外クラスは増やすべきではない。 ということで、これはむしろ、「他の例外クラスを継承しただけの例外クラスを作らない」とするのがいいんじゃないだろうか？ という点に不同意でしたので、その理由を詳しく書いてみます。 まず、 中身がない例外クラスを作る目的としては、クラス名で例外の具体的な状況が表したいというのが大きいと思う。 とあります。確かにその面は大きいですが、それと同時にエラーなどの種類や状況によって処理を変えたいという場合がある（そうなる可能性がある）と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
