# 目次
# はじめに
以下の記事は，オライリージャパン社から出版された
『プログラマが知るべき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
27. 死ぬはずのプログラムを無理に生かしておいてはいけない ヴェリティ・ストブ (Verity Stob)：『プログラマが知るべき97のこと』:
私は以前，C++の例外処理に関し，
こんな文章を書いたことがあります．
try-catchブロックをコードベースに大量に入れれば，
「例外が発生しても絶対に止まらない」
というアプリケーションを作ることが可能なはずです．
ただ，これは，もう死んでいる人を釘か何かで固定し，
無理やり立った状態にしているようなものなのですが．．．
不謹慎だと思われるかもしれませんが，
これは一種の風刺であり，
また自分自身の苦い経験から得た教訓の要約でもあります．
苦い経験とは，
自社で作成したC++ライブラリのアプリケーション基底クラスのことです．
そのクラスは，何年にもわたり
大勢のプログラマが手を加えてきたクラスだったのですが，
問題はプログラマ全員の手が「汚れていた」ことです．
そのクラスには，発生後どこにも処理されることがない例外を
一手に引き受けるコードが含まれていました．
私たちは，小説『キャッチ=22』の主人公ヨッサリアンのように，
「このクラスのインスタンスは，一旦生まれたら，
自らの意思で死なない限り，永遠に生き続けるようにすべきだろう」
と判断しました．
正確には，「判断した」というより，
「そう感じた」と言った方がいいかもしれません．
（判断したと言うと，この怪物のようなクラスの構造について，
私たちが深く考え，あれこれ検討したように聞こえますが，，
実際はそうではないのです．）
インスタンスを決して死なせないため，
私たちは，
複数の例外ハンドラを組み合わせるという方法を取りました．
WindowsのSEH(Structured Exception Handing:構造化例外処理)
とC++のネイティブの例外処理メカニズムを組み合わせたのです．
（ネイティブのC++に
__try....__exceptという構文は無いので，
Windowsでこんなものが使えるなんて知りませんでした）．
何か予期せぬ事態が起きた時には，
何度でも同様のパラメータが渡され，
例外処理のコードが繰り返し呼び出されるようにしました．
今考えると，
try-catchブロックを別のtry-catch節の中に書いたときに，
なんとなく嫌な感じがした気がします．
なんとなく「正しい道からは外れてしまったな」という感じ，
そして
「魅力的だけれども，不健康で狂気をはらんだ道に入ってしまったな」，
そんな感じもした気がします．
でも，それはきっと後知恵に過ぎないのでしょう．
この基底クラスを継承したアプリケーションで何か問題が起きても，
その問題は，まるで波止場でマフィアに殺された人間のように，
跡形もなく姿を消してしまいます．
どんなことが起きたのか，
それを知るほんの僅かな手掛かりさえも残らないのです．
普通ならば，ダンプが吐かれて状況が記憶されるような場合でも，
何も残らないのです．
後になって，
本当に随分後になってからですが，
私たちは自分たちがしたことの意味を知り，
恥ずかしい思いをしました．
そしてその異状なメカニズムを破棄し，
変わりに最小限の例外処理と通知をするだけの堅牢なメカニズムを組み込みました．
ただ，そうすると今度は，クラッシュが頻繁に起きるようになって
その対策が必要になりました．
こんな話をしても，
「それがどうした」
と思う読者が多いかもしれません．
確かにこんなバカなことをする人はめったにいないでしょう．
しかし，私は最近，
インターネット上でこんな人物に遭遇しました．
肩書きからして，もう少し物分りが良くてもいい人です．
私はその人と，
リモートトランザクションのためのJavaコードについて議論を交わしたのですが，
「コードに何か問題が起きたら，
例外はその場で捕まえ，握りつぶせばいい」
と彼は主張したのです．
（私はそれに対し，
「で，その後どうするんですか？
夕食のおかずにでもするんですか？」
と問い返しました．）
彼は，
「例外に関する情報をユーザの目に触れさせてはならない
（NEVER LET THE USER SEE AN EXCEPTION REPORT)」
それがUIデザイナ-の掟だ，
と言ってきました．
すべてを大文字で打った所から見て，
これさえ言えば話は終わるだろうと思ったようでした．
銀行のＡＴＭなどで突然ブルースクリーンが出ることがまれにありますが，
そうゆうＡＴＭのコードを書いているのは，
彼のような人間なんじゃないか，
と思ってしまいます．
ＡＴＭでブルースクリーンが出たりすれば，
ブログなどに書かれて，
その噂はすぐに広まります．
開発元の信用は失われ，
簡単には戻らないでしょう．
いずれにしても，
もし彼に会うようなことがあれば，
会釈だけして，
即座にその場を立ち去った方が賢明でしょうね．
■著者データ
[ヴェリティ・ストブ (Verity Stob)]
イギリスのロンドンを拠点とするプログラマ
"Verity Stob"は，本名ではなく偽名である．
本人の自己申告によれば，
Ｃ＋＋や一般的な（コードで中括弧を使うような）
スクリプト言語が得意で，
数多くのプラットフォーム向けに
設計やコーディングの経験を積んできたという．
だが，おそらく彼女がが最も幸せで，かつ周りも幸せなのは，
CodeGear DelphiでWindowsプログラムを作っている時であろう．
20年にもわたり，多数の雑誌，新聞，Webサイトなどに
記事やコラムを書いており，
一定の評価を得ている．
寄稿した媒体の中には，今や伝説となった
（つまり，随分昔になくなった）
「.EXE Magazine」や，
まだ記憶に新しい
(つまりまだなくなって間もない）
「Dr. Dobb's Journal」などもあれば，
少々下品な（つまり，結構お金になる）
「The Register」などもある．
2005年には，これまで書いてきたものを集め，
『The Best of Verity Stob』
Apress
売り上げランキング: 793068
として，出版した．
これで，本人の長年の夢
「一つの仕事で二回お金をもらう」
を実現したことになる．
Wikipediaに彼女についての項があるが，
本人はその記述について
「簡潔すぎるし，事実とは異なっていることも多い」
と言っている．
関連記事
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
21. 技術的例外とビジネス例外を明確に区別する Dan Bergh Johnsson：『プログラマが知るべき97のこと』 - MY ENIGMA
22. 一万時間の訓練 Jon Jagger：『プログラマが知るべき97のこと』 - MY ENIGMA
23. ドメイン特化言語 Michael Hunger：『プログラマが知るべき97のこと』 - MY ENIGMA
24. 変更を恐れない Mike Lewis：『プログラマが知るべき97のこと』 - MY ENIGMA
25. 見られて恥ずかしいデータは使わないこと Rod Begbie：『プログラマが知るべき97のこと』 - MY ENIGMA
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
