Javaにおける例外処理のベスト・プラクティス | Money Forward Engineers' Blog
PHPにおける例外クラスの設計考察
この記事はPHP Advent Calendar 2017の2日目です。 ここ最近、本業のほうが死ぬほど忙しく、すっかりブログを書いていなかった@Hirakuです。 だいぶ前のことですが、今年のPHPカンファレンス福岡で例外の話をしてきました。 この時の発表では例外に関する概要が主だったので、例外クラスそのものの設計について補足を書いてみることにします。 例外のある世界観 PHP7ではいくつかのエラーが例外と同じ挙動を示すようになり、エラーではなく例外機構を使う言語に様変わりしました。 例外というのは、かなり侵略性の高い概念であり、例外のある世界では以下の前提に立つことが暗黙のうちに強要されます。 どこでも例外が発生する可能性がある 例外によって中断されても、ソフトウェアが不適切な状態にならないように保証するのは各プログラマの責任(例外安全) たとえば、以下の関数で例外が発生する可能性があ
契約による設計から見た例外 - Qiita
正しさは相対的な概念である。 Bertrand Meyer [1] Bertrand Meyer氏は「契約による設計」という概念から例外を導出し、例外の必要性をエレガントに説明しています。また、彼の説明に則れば今までの議論と比べて例外をいくぶんか形式的に扱えるようになります。契約による設計を学ぶ前に、プログラムの正しさについてもう一度考えてみましょう。 プログラムの正しさ あるプログラムが正しいかどうかを判定するにはどのようにすれば良いでしょうか。最も簡単な方法は、あるプログラムの正しさを形式的に定義する事です。より直接的に言えば、あるプログラムの正しさを簡単な論理式で表現します。その論理式が真ならばそのプログラムは正しい。偽ならばそのプログラムは正しくありません。 これだけだと関数の戻り値を検査すれば良いだけのようにも聞こえます。しかし、そう簡単な話ではありません。純粋でない言語の場合、
Java/Androidにおける例外設計、あるいは「契約による設計」によるシンプルさの追求 - Qiita
なぜ今Javaの例外処理か Javaにおける「チェック例外」はSwift、Objective-C、Ruby、JavaScriptといったネイティブ・ウェブアプリ開発でよく用いられる他の言語には現れないものです。 SwiftにはOptionalやErrorTypeがありますが、Javaにおいてもnullやエラーのハンドリングの実装方法をうまくやる必要があります。 なぜ例外を握りつぶしたらいけないのか、なぜアサーションが望ましいのか、なぜチェック例外と非チェックを分けたのか、という点を考えてみたいと思います。 参考資料 例外設計における大罪 （契約プログラミングについて） Effective Java読書会9日目 - 例外 （Javaにおける例外の扱いについて） 契約による設計から見た例外 （この記事の方がより詳しいけど難しいイメージ） チェック例外と非チェック例外の違い チェック例外→「回復
例外処理の指針 - Qiita
C言語上がりの私にとって、例外処理という存在そのものは知っていたが、概念がC言語になかったので扱いにかなり戸惑う。 そして色々調べてみたけど、例外に関する指針・考え方は本当に多岐にわたっていて、混乱する。 ここでは、自分の解釈をまとめていくのを目標としています。 少しずつ、少しずつ、加筆してまとめていけたらと思います。 例外処理の前提 個人的には、「契約による設計」を前提とした例外処理の考え方がしっくりくる。 なので、基本的にはその考え方から例外処理を扱っていきたいと思う。 会社に買ってもらった「オブジェクト指向入門 第2版 原則・コンセプト」に契約による設計の説明と例外処理のコンセプトが書いてあるっぽい。たぶん必読なので、読む。（ぱっと見たところ、疑似言語とか出てきてて決して読みやすそうとは思わなかったが・・・） 関数失敗時に例外処理を投げるか戻り値で通知するかの指針について 某所で質問
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
