skillup

技術ブログ

アーキテクト設計全般

例外発生時で考えるべきポイント

投稿日:2023年7月29日 更新日:

いままでもいろいろ考えてきましたが、例外が発生した時のポイント(あるいはその周辺)について再度考えて見ようと思います。

トランザクションスコープ

どこからどこまでをトランザクションの1範囲とするか、議論になりやすい対象のポイントとしては、

  • 単一レコード
  • 複数レコード(一定のグループ)

でしょうか。

トランザクション自体はできるだけ小さくまとめたほうが、デッドロックのリスクがないので、なるべく小さいほうがよいでしょう。

どんな例外をなげるか

通常のExceptionとして処理をするのか、あるいはカスタマイズした例外としてなげるのか。

できればなるべく細かいExceptionを投げたほうが、検知や障害対応がしやすいのでいいでしょう。

カスタマイズ例としては500エラー以外にはいかのようなものがあげられるとおもいます。

UnauthorizeException・・なんらかの権限がない403系のエラー

ValidException・・入力値などの検証が不完全なバリデーション系のエラー

例外を発生させたあとの検知

例外を出した後の処理ですが、なんらかのほうほうで検知、記録しておく必要性があると思います。

代表的な手法としては

  • メールで連絡する
  • エラーレポーティングサービス(例:Sentry)
  • Slackなどのコミュニケーションツールに投稿する
  • 独自にLogに記録する

などでしょうか。

後続処理

その場で処理をストップさせるかあるいは、エラーの記録だけをのこしてつづけるか。

一般的にはその場でストップさせることが多いかと思いますが、データを取り込んで1行ずつ実行していくような大量処理系のバッチ処理の場合、logに記録をのこして後続処理を継続する・・・などのパターンもあります。

 

 

-アーキテクト設計全般
-

執筆者:


comment

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

関連記事

no image

ここ1年ぐらいで再確認したネタなど

今の現場では比較的、いわゆるモダンな環境で開発をしていることもあり、非常に勉強になります。 今の現場に入る前に10年近くはPHPをやっていますが、まだまだ知らないこと(といいますか新しいことがふえてき …

no image

エラーの告知や収集、通知などについて

障害対応時は基本的にエラーの情報を見て以下のようなことを考えることになりますが、 どういうエラーを出すのか どのようにエラーを拾うのか システム管理者にどのように告知するのか などはいろいろ議論の余地 …

no image

型の意識について(ValueObjectの活用など)

現在の現場でコードレビューをしてもらう機会が増え、自分が弱かった型の意識について。 現在ではPHPでも型を記述してコーディングすることが一般的なため、静的言語と同じように型を意識することが増えてきたか …

no image

Facadeパターンについて(Laravelを題材に)

LaravelのFacadeについて自作する機会があったので、メモ。 デザインパターンの一種かと思います。 Contents1 サンプル2 使い所3 メリット4 デメリット5 参考リンク サンプル h …

no image

テストコードの粒度に関して

テストコードを書いていることの悩みの1つにテストコードをどの粒度で書けばいいのか、ということがあります。 例えばバッチの場合、大きく分けると エントリーポイントのFeatureテスト Unitテスト( …

アーカイブ