上記のようなケースはわかりやすいのですが、ビジネスロジック上でも通常では起こりえないケースにて記します。ユーザー情報を定義するメソッドでユーザーが存在しない通常処理であれば在庫があるはずなのに在庫がマイナスになってしまっている絶対必要なはずの引数が存在していない・・・(上記のようなケースは設計やプログラムがしっかりしていれば防げるため、書くべきでないというかたもいるようです。)以下ではそのようなエラーを書く時に気をつけるべきことを明記していきたいと思っております。RuntimeExceptionなどとするのではなく、RuntimeExceptionを継承して、個別にクラスを分けましょう。通常のコードを書く時と同じですが、分類し、細かく分けることが必要になってきます。そのためにいきなりコードを書くのではなく、どういったエラーがあるかをまず分類する、メモとして残す必要が出てきます。try{}catchを適切な長さにする通常のコードを描くときと同じですが、スコープが長すぎると原因の追及などが追えなくなったりします。try{}catchでcatch時にrollback、(正常系の最後に)commitなどと書くケースが多いですが、これまたスコープが長すぎると、非常に不便になります。通知処理(画面)画面に出す情報はユーザーにわかりやすくしましょう。詳細なエラーメッセージ(スタックトレースなどを)画面に出してもユーザーにはわかりません。障害報告などがあった時に原因を検知しやすくするため、何がまずいのかを記しましょう。「システムエラーです」では何が悪いかわかりません。通知処理(告知)障害があった時にいち早く気づけるように通知ライブラリを使うなどしましょう。Sentryについてエラーコード上記のユーザー側に出すエラーですが、できればエラーを分類し、コード化しておきましょう。することでどんなエラーがあり、どう対処すればいいかがわかります。開発と本番で表記を分ける画面に出す情報を開発と本番で分けるようにしましょう、例として詳細なスタックトレースを開発時には画面に出しておき、本番では伏せ、エラーコードだけにするなどです。コメントをキャンセルメールアドレスが公開されることはありません。※サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。関連記事ログ対策(どのように情報を抽出するか)現在、現場でテストをやってるんですが、やることは昔と変わらずテストデータ作り、ログ、エラーハンドリングになります。3年近くまえに↓のような記事をかいてました。...abstract,interface,traitなどについて昔はようわからなかったabstract(継承全般)、interface、traitの使い分けなどについて。...気をつけたいトリガー系の処理など実務でひやっとすることがあり、自分への戒めも込めてメモします。...テストコードを読みやすくするリーダブルコードも最終章に近づいてきましたね。今回はテストコードについて。メモリとポインタ、配列と連結リストWEB+DB(vol91)で使えそうな連載記事がありますのでブログにメモリます。テーマはデータ構造です。