【ソフトウェア設計】例外処理を考える
はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？ 予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。
凄腕エンジニアさんから学んだ例外の話 - Qiita
はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトのエンジニアさんに伝えたところ、反応が良く、とても勉強になりました！という声をいただけたので、アウトプットしていきたいと思います。 （この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。） ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth
エラー画面やAPIエラーから独自エラーまで！ フローチャートでちゃんと理解するLaravelの例外処理とケーススタディ - Qiita
エラー画面やAPIエラーから独自エラーまで！ フローチャートでちゃんと理解するLaravelの例外処理とケーススタディPHPLaravelexceptionlaravel5.5 TL;DR Laravel 5.5 ベース（Laravel 5.7 まで対応） フローチャートでおおまかな処理の流れと、どこでどんなことをするのかを解説します それを踏まえて「こんな時はこうする」というケーススタディを紹介 中小規模のプロジェクトにはそのままコピペで使ってもらえるベストプラクティス的なものを目指しています 実際にこれをベースにしたものが中規模業務アプリに実装されています バリデータ編もあります。 → フロー図で理解するLaravelバリデータの仕組みと、チーム開発でのケーススタディ 動機 個人的にエラー処理の仕組みを理解するために書いたチャートです 自分で勉強しようとしたとき、Laravelのエラー
Condition Systems in an Exceptional Language - Chris Houser
"Some errors, however, are sufficiently obscure to escape detection for a surprisingly long time." -Brooker and Wheeler, 1952 Clojure does not come with a Condition system as powerful as Common Lisp's. Instead, we have Exceptions, which start unwinding the stack the moment they're thrown, destroying information as they go. The values of locals disappear, and there is no ability to continue from t
Ruby関西 勉強会で「プロを目指す人のための例外処理（再）入門」という発表をしてきました #rubykansai - give IT a try
はじめに 2017年1月13日（土）に開催された第80回 Ruby関西勉強会で「プロを目指す人のための例外処理（再）入門」という発表をしてきました。 会場はすごくきれいで快適な、大阪梅田のグランフロントにあるAimingさんでした。 （どうもありがとうございました！） このエントリでは僕の発表内容と、勉強会中のエピソードを書いていきます。 発表スライド 当日使用した僕の発表スライドはこちらです。 例外処理については過去にいろいろ痛い目に遭わされているのと、間違った使い方をしている初心者さんをよく見かけるので、「お願いだから正しく使って！！」という気持ちでこのスライドを作りました😅 例外処理にまつわる僕の体験談については「本当にあった怖い話」としてスライド内で紹介していますw その他にも例外処理のバッドプラクティスやベストプラクティスなど、例外処理を書くときは絶対に押さえておきたいポイント
『異常系とは何であるか考えよう』
悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 システムのテストを行う際、テストの内容を「正常系」と「異常系」に分類することがある。それぞれのテスト項目数や不具合の発生数などを数えて、テストの妥当性や品質の判断に使ったりするのである。 この正常系、異常系という言葉はよく耳にするのだが、その意味は曖昧であることが多い。人によって解釈が違うのである。 例えば、「ユーザーが入力ミスをしたケース」について、「正常な値が入力されていないのだから異常系だ」という人もいれば、「開発者がミスを想定していて、プログラムで入力チェックをしてメッセージを出すなどの処理をしていれば正常系だ」という人もいる。 これは、異常系のテストを、「エラー・ハ
正常系と異常系の区別とドキュメントの書き方について - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 正常系と異常系について、テストの観点から書かれているものが多い。 そして、区別が曖昧なものも多いです。 ところが、ソフトウェア工学の観点から見ると、これは、明確に分かれます。 →ユースケース記述で そして、開発上、重要な意味を持つので、ちょっと所見を書いてみます。 ■正常系とは ＜＜ソフトウェア工学的には：たぶん＞＞ ・事前条件が成立するときに、事後条件が成立するケースが正常 ＜＜解説＞＞ ある処理に対して、入力値が適切であるとき、 処理終了後の状態が、期待している通りになっているもの →期待している成果物ができている状態 ■正常系でないとは ＜＜ソフトウェア工学的には：たぶん＞＞ ２とおりある ・事前条件が成立しないケース ・事前条件は成立するが、事後条件が成立しないケース ＜
Javaの検査例外は、呼び出し側で「どんなに注意しても防げない」異常系 - Qiita
注：本記事の内容はJavaで公式にドキュメントされているものではなく筆者の見解です。とはいえクラスを設計する上で有用な指針たり得ると思われるので公開したものです。 おさらい - 検査例外と非検査例外 Javaの例外クラスには「catchしないとコンパイルエラーになる」検査例外（チェック例外、checked exception）とそうでない非検査例外（非チェック例外、unchecked exception）があります。 検査例外は最近は嫌われる傾向がありC#では採用されていませんしAltJava言語も軒並み不採用、さらにはJavaの新しめのライブラリにも非検査例外しか投げないものが出てきていますが、適切に使えば安全なプログラミングのための強力な武器であり、検査例外の有意義さについては @irxground さんの Javaの検査例外の存在意義 をご覧ください。 例外クラスを自作する場合、検査
契約による設計から見た例外 - Qiita
正しさは相対的な概念である。 Bertrand Meyer [1] Bertrand Meyer氏は「契約による設計」という概念から例外を導出し、例外の必要性をエレガントに説明しています。また、彼の説明に則れば今までの議論と比べて例外をいくぶんか形式的に扱えるようになります。契約による設計を学ぶ前に、プログラムの正しさについてもう一度考えてみましょう。 プログラムの正しさ あるプログラムが正しいかどうかを判定するにはどのようにすれば良いでしょうか。最も簡単な方法は、あるプログラムの正しさを形式的に定義する事です。より直接的に言えば、あるプログラムの正しさを簡単な論理式で表現します。その論理式が真ならばそのプログラムは正しい。偽ならばそのプログラムは正しくありません。 これだけだと関数の戻り値を検査すれば良いだけのようにも聞こえます。しかし、そう簡単な話ではありません。純粋でない言語の場合、
エラー処理設計：対処方法をシステム全体で定める
システムのエラー処理を総合的に設計する どんなシステムでもエラー処理は欠かせず、たいていは大きな割合を占める。システム上のエラーはもちろん、業務上に代表される問題領域のエラーまで対応しなければならないからだ。エラー処理の基本は、エラーを検出し、その結果によって適切な処理を実行すること。しかし、システム全体でみれば、異なるタイプのエラーが数多くあるため、エラー処理が分散するし、エラーの種類ごとに対処が違う。完成度の高いシステムを目指すなら、全部のエラーを把握しながら、システムを設計する必要がある。 一部のエラー処理は、システムの基本構造と深く関係している。エラー処理を重視すると、システムの基本構造に影響を与える。逆に、システムの基本構造がエラー処理の一部を制限することもある。仕方がないので、両者の妥協点を見付けるしかない。 この点を考慮し、次のような手順で基本構造を設計する。最初は、エラーが
scala.util.control.Exceptionとscala.util.Tryを使った例外処理
scala-loggingを使ってみる 概要 例外の取り扱いをする場合にどれを使うのが適切なのかわからなくなったので、scala.util.control.Exceptionとscala.util.Try、両クラスの各機能をざっと使ってみる。 前半はscala.util.control.Exception, 後半はscala.util.Try。 allCatch optでOptionを戻り値に とりあえずallCatchですべての例外をcatchする処理を書く。 最も手軽に使えそうなのがopt。例外だったらNone、成功すればSome(x)を返す。 import scala.util.control.Exception._ def divide(x: Int, y: Int) = allCatch opt { x / y } var result = divide(0, 0) printl
良いエラーメッセージの書き方 - Qiita
エラーには大抵「エラーメッセージ」が付いています。 自分は過去に、エラーメッセージの内容を雑にしてしまい後悔することがよくありました。 その経験から、良いエラーメッセージの書き方を考えました。 エラーメッセージを2つに分類する まず、エラーメッセージといっても次の2つのパターンで大きく異なってきます。 (1) ユーザーが見るエラーメッセージ (2) 開発者が見るエラーメッセージ (1) ユーザーが見るエラーメッセージ 内部実装のことは書かないようにする
Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita
これは Swift Tweets の発表をまとめたものです（次回開催はこちら）。イベントのスポンサーとして Qiita に許可をいただいた上で投稿しています。 ありがとうございました！Q&Aは他の人の発表中でも構わないのでリプを飛ばして下さい。 続いては僕 @koher の発表で、タイトルは "Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい" です。 #swtws — koher (@koher) 2017年1月14日 第 1 部: Swift の 4 種類のエラーについて あまり知られてませんが、エラー処理について、 Swift 2.0 設計時に Core Team がまとめた "Error Handling Rationale and Proposal" というドキュメントがあります。このドキュメントは、僕が去年 try! Swift で発表した際にも参考文献にしまし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
"Good Enough" error handling in Clojure | Adam Bard, Handsome Web Developer
Function Failure reporting: Error or OK
例外設計における大罪 - 契約