skillup

技術ブログ

プログラミング全般

例外処理に関して

投稿日:2020年5月22日 更新日:

いまいち使い方がいい加減だった例外処理について、復習がてらメモします。

昔のリンクを整理して出てきた例外リンクはこちら(Javaですが今のPHPにも当てはまるかと思います。)

例外処理について

例外処理について その2

例外は例外の時に

読んで字のごとくですが、通常では起こりえない時に「例外」を発生させます。

典型的なのは以下のようなケースですね。

  • メモリのオーバーフロー
  • DB接続失敗
  • アクセス制御失敗
  • ファイルなどが不存在

通常、プログラマが制御可能なもの( Exception )と制御不可能なもの( Error )に分かれます。

Error とは StackOverflow のようにプログラマが直接制御するのが極めて難しいものになります。基本的には Exception の部分に記述して行くことになるかと思います。

RuntimeException

Exceptionの中でも、Fileがない(FileNotFoundException)、クラスがない(ClassNotFoundException)などは必須の処理になりますが、それ以外の任意で追加するエラーのものは RuntimeException となります。

なお、細かいクラス分けは例外処理について その2を参考に。

上記のようなケースはわかりやすいのですが、ビジネスロジック上でも通常では起こりえないケースにて記します。

  • ユーザー情報を定義するメソッドでユーザーが存在しない
  • 通常処理であれば在庫があるはずなのに在庫がマイナスになってしまっている
  • 絶対必要なはずの引数が存在していない

・・・

(上記のようなケースは設計やプログラムがしっかりしていれば防げるため、書くべきでないというかたもいるようです。)

以下ではそのようなエラーを書く時に気をつけるべきことを明記していきたいと思っております。

エラークラスを細かく分ける

全てthrow RuntimeExceptionなどとするのではなく、RuntimeExceptionを継承して、個別にクラスを分けましょう。

通常のコードを書く時と同じですが、分類し、細かく分けることが必要になってきます。

そのためにいきなりコードを書くのではなく、どういったエラーがあるかをまず分類する、メモとして残す必要が出てきます。

try{}catchを適切な長さにする

通常のコードを描くときと同じですが、スコープが長すぎると原因の追及などが追えなくなったりします。またtry{}catchでcatch時にrollback、(正常系の最後に)commitなどと書くケースが多いですが、これまたスコープが長すぎると、非常に不便になります。

通知処理(画面)

画面に出す情報はユーザーにわかりやすくしましょう。詳細なエラーメッセージ(スタックトレースなどを)画面に出してもユーザーにはわかりません。

障害報告などがあった時に原因を検知しやすくするため、何がまずいのかを記しましょう。「システムエラーです」では何が悪いかわかりません。コードがあれば別ですが・・・・

通知処理(告知)

障害があった時にいち早く気づけるように通知ライブラリを使うなどしましょう。

エラーレポーティングサービス Sentryについて

エラーコード

上記のユーザー側に出すエラーですが、できればエラーを分類し、コード化しておきましょう。

そうすることでどんなエラーがあり、どう対処すればいいかがわかります。

開発と本番で表記を分ける

画面に出す情報を開発と本番で分けるようにしましょう、例として詳細なスタックトレースを開発時には画面に出しておき、本番では伏せ、エラーコードだけにするなどです。

参考になったリンク

PHPの例外

複雑さに潜り込む – 大規模PHPアプリケーションにおける例外・モニタリング・ロギング

このネタはまた書くかもです・・

-プログラミング全般
-,

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

コードの見た目について

リーダブルコード4章。コードの見た目について。 自分は結構注意されますね。多いパターンとしては空白の位置などがいい加減だったり、今はありませんが、以前はコードの末尾にスペースを空けてセミコロンをうつ変 …

no image

Eclipseでのソースフォーマットでの自動改行を防ぐ

小ネタ。Eclipseのソースフォーマッタはディフォルトでは一定の字数で改行されしまい、大変見にくくなったりします。 またHTMLなどでは改行してほしいタグが改行されないなど思ったとおりに動いてくれま …

no image

APIに関して

RESTAPIのルーティングで気をつけることなんぞを。 直近のプロジェクトではRESTAPIを作ることが多かったんですが気をつけることなんぞを。 Contents1 仕様書はソースから2 ツール3 命 …

no image

テストコードを読みやすくする

リーダブルコードも最終章に近づいてきましたね。 今回はテストコードについて。 以前のプロジェクトではテストコードを書いていたのですが、今携わっているプロジェクトでは書いてないです・・・ テストを書く目 …

no image

コレクションの頻出処理に関して

PHPでコレクションを使っていますが、慣れると本当に便利ですね・・・まあforeachとかでグリグリやってもいいのですが、無駄にコードが長くなります。 自分がコレクションでよく使う再頻出のメソッドなど …