# 目次
- 21. 技術的例外とビジネス例外を明確に区別する ダン・バーグ・ヨーンソン (Dan Bergh Johnsson)：『プログラマが知るべき97のこと』
- 関連記事
- MyEnigma Supporters
# はじめに
以下の記事は，オライリージャパン社から出版された
『プログラマが知るべき97のこと』
の中から1つのエッセイを選び，
そのエッセイを，クリエイティブコモンズ3.0の条件の元で転載したものです．
Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0
本書の内容は，オープンソースモデルに従い，
ほぼ無制限で利用が可能です．
クリエイティブ・コモンズ表示3.0の条件下で，
自由に使用することができるのです．
つまり，どのエッセイも，
著者の名前を明記すれば，自由に転載，改変が可能であるということです．
ーー"はじめに"から抜粋 pXII
もし，他のエッセイを読みたい場合には，
記事末のリンクを辿るか，
以下のリンク先のTwitterアカウントのつぶやきからお探し下さい．
Twitter Account: 97 Things Bot
また，元の英文によるエッセイを読みたい方は，
こちらを参照して下さい．
Contributions Appearing in the Book - Programmer 97-things
21. 技術的例外とビジネス例外を明確に区別する ダン・バーグ・ヨーンソン (Dan Bergh Johnsson)：『プログラマが知るべき97のこと』
プログラムの実行時に起きる問題には，
大きく分けて２つの原因があります．
一つは技術的な原因です．
これは，発生するとアプリケーションの実行そのものが
続けられなくなるような問題です．
もう一つの原因はビジネスロジックで，
これは簡単に言えば，
ユーザがアプリケーションの使い方を間違えさせないために
（わざと）発生させる問題です．
「モダンな」プログラミング言語
LISP*1，Java，Smalltalk*2, C#などは，
この二種類の問題の発生を通知させるために，
「例外（Exception）」を使用します．
しかし，
二種類の問題は本質的に大きくことなるものなので，
混同しないように常に注意する必要があります．
両者を同じ例外階層構造を使って表現することは，
混乱の元になりますし，
ましてや同じ例外クラスで表現するのはもってのほかです．
プログラムのコードに誤りがあると，
解決が難しい「技術的な問題」が発生することがあります．
例えば，要素が17個しかない配列の
83番目の要素にアクセスするようなコードを書くと，
プログラムは間違いなくまともに動かず，
例外が発生するでしょう．
そこまで極端ではなくても，
例えば，ライブラリのコードを呼び出すときに引数が適切でなかったりすると，
ライブラリ内部で同様のことが起こるでしょう．
この種の例外を処理するコードを自分の手が書くのは懸命とは言えません．
発生した例外を自分で捕まえずにトップレベル，
アーキテクチャレベルまで通過させ，
トップレベルの例外処理メカニズムのに後の処理を委ねるのです．
トップレベルの例外処理メカニズムは処理を依頼されると，
システムを安全な状態に戻すための対処をします．
具体的には，トランザクションのロールバック，ログ作成，
管理者への警告，ユーザへの通知（管理者への警告より表現は穏やかになる），
などを行います．
ライブラリ内で問題が発生した場合も同様のことが言えます．
例えば，メソッド呼び出しのコードが
ライブラリの契約(Contract)に違反していた場合などです．
契約違反とは具体的には，渡す引数が正しくない，
必要なオブジェクトが正しくセットアップできていない，
といったことを意味します．
これも「技術的な問題」の一種です．
要素が17個しかない配列の83番目にアクセスしようとする，
というのと重大さの点ではさほど変わりません．
これは本来，呼び出し側のコードでチェックされるべきなのですが，
もし，チェックが行われないのだとすれば，
それはクライアント側のプログラマのミスということになります．
呼び出し側コードでの正しい対処は，自分で例外を発生させることです．
データベースサーバが応答しない等，
実行環境の不備によって
プログラムの実行が続けられない，
という状況も考えられます．
これは上記の問題とは異なりますが，
やはり技術的な問題であることはたしかです．
本来は，インフラの側がなんらかの対処
（接続を修復する，何度かリトライする，など）
をするべきなのですが，
それが失敗に終わったという状況です．
先の二つとは原因が違いますが，
解決するためにできることがほとんどないという点は同じです．
発生した例外を捕まえずに通過させて状況を通知し，
トップレベルの例外処理メカニズムに対処を委ねるしかないでしょう．
ここまで述べた技術的な問題とは違い，
「ビジネスロック」は，
業務ロジックの判断により，
プログラムの実行が中断されるような状況です．
確かに普通の状況ではないし，
望ましい状況でもないのですが，
技術上の問題が起きた時ほど深刻ではありません．
プログラム自体に問題がある，というわけではないからです．
例えば「ユーザが，預金額を超える額のお金を口座から引き落とそうとした」，
というような問題を指します．
これは先ほど述べた契約(Contract)の一部と言ってもいいでしょう．
この状況で例外を発生させることは，
モデルに含まれた代替パスの一つにすぎないのです．
つまり，クライアントの方で，
あらかじめこの状況に対処するコードを組み込んでおく
必要があるということです．
発生させる例外は，この状況にのみ対応する例外を新たに定義するか，
あるいは，技術的な例外とは異なる例外階層構造に属するものにすべきです．
システム全体に影響を与えず，
クライアントだけで問題に対処できるようにするのです．
「技術的例外」と「ビジネス例外」を同じ例外階層構造で扱ってしまうと，
両者の区別は曖昧になってしまいます．
メソッドの契約に違反していても，それがわからず，
メソッドを呼び出す際にどういう事前条件を
満たさなければならないのかもわかりません．
例外が発生したときに
クライアントのコードで処理するべきかも判断できません．
二つの例外を明確に区別して扱うようにすれば，
そういうことは起きません．
技術的例外に関しては，
アプリケーションのフレームワークに
対応を任せることができ，
ビジネス例外に関しては，
クライアントにあらかじめ対処するコードを組み込んでおくことができます．
■著者データ
[スティーブ・P・バーチャック (Steve Berczuk)]
Omegapoint AB社のシニアコンサルタント，
パートナー，オフィシャルスポークスパーソン．
個人的にはドメイン駆動設計に傾倒しており，
アジャイルソフトウェア開発の長年の支持者である．
自らを伝統的なソフトウェア職人の一人であり，
「OOPSLA学派」の一員でもあると，捉えている．
スウェーデンのドメイン駆動設計グループ
"DDD Sverige"の共同設計者の一人であり，
DDDの本系サイト
Domain-Driven Design Community
に寄稿するだけでなく，
国際的なカンファレンスでプレゼンテーションを行う機会も多い．
彼の職人仕事への愛情は
Dear Junior - Letters to a Junior Programmer
でもうかがい知ることができる．
関連記事
1．分別のある行動 Seb Rose：『プログラマが知るべき97のこと』 - MY ENIGMA
2．関数プログラミングを学ぶことの重要性 Edward Garson：『プログラマが知るべき97のこと』 - MY ENIGMA
3．ユーザが何をするかを観察する (あなたはユーザではない) Giles Colborne：『プログラマが知るべき97のこと』 - MY ENIGMA
4．コーディング規約を自動化する Filip van Laenen：『プログラマが知るべき97のこと』 - MY ENIGMA
5．美はシンプルさに宿る Jorn Olmheim：『プログラマが知るべき97のこと』 - MY ENIGMA
6．リファクタリングの際に注意すべきこと Rajith Attapattu：『プログラマが知るべき97のこと』 - MY ENIGMA
7．共有は慎重に Udi Dahan：『プログラマが知るべき97のこと』 - MY ENIGMA
8. ボーイスカウト・ルール Robert C. Martin：『プログラマが知るべき97のこと』 - MY ENIGMA
9. 他人よりまず自分を疑う Allan Kelly：『プログラマが知るべき97のこと』 - MY ENIGMA
10. ツールの選択は慎重に Giovanni Asproni：『プログラマが知るべき97のこと』 - MY ENIGMA
11. ドメインの言葉を使ったコード Dan North：『プログラマが知るべき97のこと』 - MY ENIGMA
12. コードは設計である Ryan Brush：『プログラマが知るべき97のこと』 - MY ENIGMA
13. コードレイアウトの重要性 Steve Freeman：『プログラマが知るべき97のこと』 - MY ENIGMA
14. コードレビュー Mattias Karlsson：『プログラマが知るべき97のこと』 - MY ENIGMA
13. コードレイアウトの重要性 Steve Freeman：『プログラマが知るべき97のこと』 - MY ENIGMA
14. コードレビュー Mattias Karlsson：『プログラマが知るべき97のこと』 - MY ENIGMA
15. コードの論理的検証 Yechiel Kimchi：『プログラマが知るべき97のこと』 - MY ENIGMA
16. コメントについてのコメント Cal Evans：『プログラマが知るべき97のこと』 - MY ENIGMA
17. コードに書けないことのみをコメントにする Kevlin Henney：『プログラマが知るべき97のこと』 - MY ENIGMA
18. 学び続ける姿勢 Clint Shank：『プログラマが知るべき97のこと』 - MY ENIGMA
19. 誰にとっての利便性か Gregor Hohpe：『プログラマが知るべき97のこと』 - MY ENIGMA
20. すばやくデプロイ，こまめにデプロイ Steve Berczuk：『プログラマが知るべき97のこと』 - MY ENIGMA
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
*1:プログラミング言語の一種である。括弧を多用する独特の構文を持つ。名称「LISP」はリスト処理を意味する英語「list processing」に由来する。全てのプログラミング言語の中でも2番目に古い高級言語であり、現在でも広く使われている。LISP - Wikipedia
*2:Simulaのオブジェクト（およびクラス）、Lispの機能、LOGOのエッセンスを組み合わせて作られたクラスベースの純粋オブジェクト指向プログラミング言語、および、それによって記述構築された統合化プログラミング環境の呼称. 豊富で整備されたクラスライブラリは、特にオブジェクト指向プログラミングの手本とされ、デザインパターンの宝庫と称されるまで洗練されたものになっている。また、後世の多くのオブジェクト指向プログラミング言語に直接間接的に多大な影響を与えた.Smalltalk - Wikipedia
