Windowsエラーメッセージ実装ガイド

ISBN4-900900-86-9 \2,800 + 税

オライリージャパンから1999/3/27に刊行されました。私は初めて訳者にならせて頂きました。
この本は、どうしたらソフトウェアが開発できるかではなく、どのようなソフトウェアを開発するべきかを説明している好著です。
この本は原著がすばらしく面白かったので、その雰囲気が残せればと思い訳しました。
本書の著者序文訳者前書き本文の一部をオライリージャパンのご理解の元に(ほぼそのまま)転載させていただきました。


著者序文

パーソナルコンピュータが初めて登場してから四半世紀が過ぎても、エラーメッセージは変わること無く必要でした。パーソナルコンピュータが登場するさらに四半世紀前のeniacからずっと必要だったのです。この半世紀の間に、排気管が張り巡らされた奇怪な建物に収められたパンチカードを使用していたコンピュータは、高い記録密度のCDやguiインタフェース,パームトップコンピュータへと進化しました。エラーメッセージはこの間に数字のコードによる表示から、本当に単純なテキストが表示されるようになったに過ぎません。
自動車の発達を考えてみると、エラーメッセージに相当するものは、人が手にしたカンテラ(手提げランプ)により前をテクテクと進む馬車が進路を妨げないようにしたことでした。これは大変有効でした。自動車産業の先駆者達は、エラーメッセージとエラーメッセージの取り扱いは別つことが出来ないことを、産業の黎明期から認識していました。これはコンピュータ業界よりも進んでいた点です。
本書の視点は、これまでのエラーメッセージと表示が、エンドユーザを考えたものではなく、プログラマや技術者向けとしか思えないものであり、とても弁解の余地は無いものであるいうことです。もっと直裁に述べるならば、多くのエラーメッセージはそのものがエラーであり、人を困惑させるだけで、邪魔物以外の何者でもないのです。
このような誤りを"いつもこうしてたのさ"と続けることは出来ません。本書、Developing Windows Error Messagesでは、どのようにエラーメッセージを表示するべきかを検討し、エラーのトラップと同じくらい有効である、エラーを抑止する方法について述べます。これはエラーを取り扱うよりもより良い方法です。本書には様々なレベルのエラーメッセージを表示するダイアログと機能をもったダイナミックリンクライブリ(.DLL)が用意されています。このライブラリとソースコードはパブリックドメインとしました。

保証:これらのサンプルには悪質なコメディルーチン(訳注:パブリックドメインによく見かけるふざけたプログラムのこと)のような問題はありません。著者は自分が欲求不満のコメディアンでないことを保証し、フィルモアイースト(訳注:ニューヨークの有名なロックコンサートホール)とかコメディークラブに立ちたいという野望もないことを誓います。
保証という観点で述べるならば、主題はアプリケーションエラーであり、エラーメッセージであり、ユーザに対して高慢でなくエラーを訂正することであり、モノキシディル(訳注:育毛剤の名前)の販売が伸びて失われたふさふさした髪の毛が蘇ることです。

本書の読者のみなさん

本書には明確な目的があります。それは嘆かわしいソフトウェアのエラーメッセージの状態を改善する一助になることです。コンピュータに興味がある人、特にソフトウェア開発に関心がある方にとって本書はお役に立つでしょう。また、いろいろと挿入しているユーモアたっぷりの短い話題があり、単なる興味深いコンピュータ本ではありません。具体的に述べるとdeveloping Windows Error Messagesは開発者に向けたものであり、コンポーネントやソフトウェアにエラーメッセージを作り込む人たちに向けたものです。エラーメッセージについて話し合ってみると、プラットホームや開発環境に関係なく改善する方法には限界があり、本書ではプラットホームに最適な記載を、つまりWin32 APIによる32ビットWindowsソフトウェアとして説明しています。コーディング例はC++を使用し、通常はMFCを併用しています。同様にVisual Basicでも説明しています。ErrorMessage.DLL(本書に対応して用意してあるダイナミックリンクライブラリ)はCからも利用でき、MFCを使用していないC++やVisual Basic、Windows DLLをサポートしている他の開発環境からも利用できます。
本書の構成
developing Windows Error Messagesは4つの章と3つのAppendixeから構成されています。
第一章 エラーメッセージのエラーは、実際の例を元にエラーメッセージにどのような誤りがあるかを分析しています。この章では、最高のエラーメッセージであってもいかに貧弱かを論じています。多くの場合で性急にプログラムソースの中に(しばしば開発者自身のためのものも)組み込んでしまうからです。
第二章 エラーの予防は、視点を変えてエラーをどのように防ぐかのかという観点から述べています。深い洞察に基づきいろいろな"エラー"を自動的に取り扱いって必要なエラー表示を取り除き、どうしたら良いのかを分かりやすくさせることで、ユーザエラーを低減させます。
エラーは、抑止し、取り扱い、限定することは出来ますが、完全に無くすことは出来ません。ですから第三章ではより人にやさしいエラー表示方法について述べ、撲滅できないエラーを人に伝える新しい表示方法についてフォーカスします。これらは本書に対応して提供されるerrormessage.dllによりすべてが実現されています。
最後の第四章エラートラッキングとサポートは、エラーのログに関連したことを述べています。ログは品質保証技術サポートのために必要なだけではなく、ユーザがアプリケーションのなにを問題にしているかを明らかにする手段でもあります。大きな問題点の一つとしてエラーメッセージを誤解することによる、ユーザの誤った理解があります。このような場合、エラーログはアプリケーションのエラー情報がどのように効果的であるかを実質的に分析する手段となるのです。
Appendix A, ErrorMessage DLLの使い方, アプリケーションがいろいろなエラーメッセージの機能を実現できるErrorMessage DLLの機能についてのドキュメントです。
Appendix B, ErrorMessage / ErrorShell DLLs の内部構造 ErrorMessage DLLのデザインについての解説です。またC のライブラリをVisual Basicから利用できるように変換するErrorShell.DLLについても説明しています。これはすでに開発済みのライブラリをVisual Basicから利用できるようにするための開発者にとって汎用的で重要な方法です。また、これらの情報はWin32プラットホームでない環境で同様に機能を実現する際に重要な情報でもあります。
第二章で述べているように、アプリケーションで繰り返し起きるであろうエラーについて可能な限り明らかにして、ユーザに知らせること無く取り扱うべきです。
Appendix Cプラグアンドプレイイベントメッセージのトラッピングはハードウェアデバイスを動的に取り外したり追加して利用可能にしたりする技術について(プラグアンドプレイでないシステムではこうしたことが深刻なエラーを招きます)解説しています。多くの場合ユーザは介在しません。

謝辞

本書の内容と誤りについての全責任は著者にありますが、本書で紹介しているエラーメッセージについての責任は著者には関わりがありません。
本書の制作にお力添えいただいた皆様に謝辞を述べさせていただきます。皆様の努力にも関わらず本書は完結しているとは申せないでしょう。私の謝辞は、まず無制限な努力を惜しまなかったRon Petrushaに捧げたいと思います。はじめの考え方を推進し拡張してくれました。次に、編集サービスのTroy Mottに感謝しております。詳細な部分にわたって様々な注意を払ってくれました。さらに謝辞をプロダクション編集者のMadeleine Newellとイメージを担当したRobert RomAno、Wordから写植に変換してくれたMike Sierra、O'LearyのClaire Cloutier LeBLANc, Clairemarie Fisher、品質保証に努力してくれたEllie Fountain Maden, JAne Ellin, Sheryl Avruch、インデックスを作成してくれたGerry Azzata(Seth MaiSTlink支援してくれました)に捧げます。最後に(とはいえ終わるわけではありませんが)カバーデザインのEdie FreedmAn、カバーレイアウトのKathleen Wilson、そしてあなたの御手元に本書が届けられるようご努力いただいたすべての皆様に感謝いたします。
本書のいたるところにお名前を載せさせていただいた皆さんに感謝いたしております。惜しみなく親切に皆さんのお気に入りのエラーメッセージをご提供いただき、どのようにエラーが起きるのかについて無数の問い合わせに繰り返しお答えいただきました。
(訳注:eniacは世界初のコンピュータとまだ誤認されているコンピュータです。コンピュータ史上ではeniacより数年前に開発されたabcが世界初と認定されておりeniacに原理を提供していたことが法廷で証明されています)


訳者前書き

ソフトウェアについて幾多のコンピュータ書がありましたが、ほとんどが"どうしたらソフトウェアを開発できるか"についてでした。それに対して本書は、"どのようなソフトウェアを開発すべきか"をテーマにしている、異色の技術書です。
より良いエラーメッセージを表示するためにはプラットホームの能力をフルに利用するという観点から、Windowsの最新機能を駆使し、ダイアログ内でIEにHTMLを表示させるということまでをサンプルを取り混ぜ示しています。こうした背景から本書のタイトルとなりましたが、本書で示されている考え方やシステムは他のプラットホームでも応用することができます。
また、コードのレビューの役割を改めるべきという提言や、具体的によく検討されたエラーの分類、技術サポートとユーザを結ぶダイアログなど、実質的な啓示に溢れています。本書は、ソフトウェア開発をされる方々、サポートをされている方々に広くお読みいただけるものですし、これからの質を問われるソフトウエア開発において、ひとつの指標を示していると言えるでしょう。
訳者はソフトウェアを生業としてから20年余が過ぎましたが、こうしたテーマが書籍になる時代がとうとう来たのだと感慨を思いました。これは本書のテーマが、日常の業務の中で訳者が若い技術者たちに伝えようと努力していた話題でもあったからです。
また、日本人という観点で本書を読むと、別な側面、つまりアメリカ(というより欧米)と日本のソフトウェア技術者の在り方との違いも気付かされます。本書にはクラフトマンシップ(職人気質ともいう場合があります) が満ちています。日本では大量生産の概念を適用するソフトウェアの開発方法/評価論の導入によりクラフトマンシップをどちらかというと否定しているともいえるので、どのようにしたらユーザを満足させられるのかという問題に真っ向から取り組んでいる著者の姿勢を真っ直ぐに受け止められない人もあるのではないでしょうか?訳者は欧米の開発者たちとのいろいろな仕事の協力の中で、彼らの中に脈々と受け継がれているクラフトマンシップを目の当たりにしてきました。これが日本製のソフトウェアが欧米のものよりも劣ると言われる原因ではないかとまで感じています。妥協しないプロの努力の積み重ねだけが、深く考えられたソフトウエアを生み出す原動力になります。そうした人々を縦横に活用したソフトウェア開発をする組織(企業)とあいまって、欧米では素晴らしいソフトウェアを開発しています。本書からそうしたところも感じていただければ幸いと思います。
本書が皆様のすばらしいソフトウェア開発の一助になりますよう祈っております。
1999年2月10日 午後3時
著者について
Ben Ezzellはフリーランスのコンサルタント/ソフトウェア技術者で、20冊以上のコンピュータプログラミングに関する書籍を執筆しています。いくつかご紹介すると、object-oriented Pascal And C++(AddISOn Wesley)、complete guide to Windows NT in HELP! Windows NT(Ziff-Davis)などがあります。また、32-Bit Windows Programming(Howard W Sams), NT 4/Windows95 Developer's HAndboOK(Sybex)があります。Benの他に興味があることは、パズル、海外旅行とエキゾチックフードです。
訳者について
古山一夫は(株)ビーコンインフォメーションテクノロジーのテクノロジーインキュベーション室の室長で、DCOMやオブジェクト指向DBについての著書や雑誌記事を多く執筆しています。オライリーの編集者の方に「気に入った本があれば訳して見ませんか」とそそのかされて柄にもなく翻訳を手がけました。古山の趣味は、オーディオ、ダイビング、酒飲みと大飯喰いです。詳しくはhttp://www2.gol.com/users/calvados をご覧ください。


第2章 エラーの予防 より

エラーを伝えることよりもさらに重要なのは、実際にエラーが起きないようにする事です。
それは、皆さんもよくご承知のことだと思います。プログラム開発プロジェクトで重要なパートを占めているのはバグの発見であり、バグの修正であり、問題が再現しないようにすることです。そして次に頭を悩ませる事が、クライアントとの打ち合わせで仕様が変わってしまい、せっかくのエラーのデバッグが無駄になってしまう事です。
しかし、ひょっとすると、ソフトウェアのエラーとはアプリケーションエラーだと思われていませんか?つまりコードの誤り、例外の処理し忘れ、誤ったポインタ、永久ループなどです。ここではこうしたエラーについてを述べようとは考えていません。もちろんアプリケーションエラーは重要です。そうしたエラーには、取り除くためにさまざまのプログラミングツールがあります。またプログラマーのために、そうしたエラーを見つけ特定する方法もいくらかあります。
ここで述べたいエラーとは、それ以外の2つのタイプのものです。
第1のものが、ユーザがなぜ起きたかを理解できなかったり、簡単に間違えてしまうためにエラーが発生するという場合です。第2のものが、アプリケーションに原因が無くエラーが引き起こされてしまう場合です。


お気に入りのエラーメッセージ#8
公開されていない機能です
後日にお知らせいたします…たぶん…

エラーと失敗

本書の読者の方は、0除算、浮動小数点のオーバーフロー、初期化し忘れた変数といったエラーなどを、どのようにトラップすれば良いかは、よくご存知であると思います。ここで述べるエラーはそうしたエラーではありません。
ここで述べるものはエラー(error)ではなく、失敗(failure)について述べ、また、エラーと失敗の違いを明らかにしたいのです。残念ですが、私にもエラーと失敗の明確な定義を簡単には出来ません。
なぜ明確にしにくいかというと、プログラムの実行時における誤りであるエラーである状態は、トラップして直ちに対応する事が出来ますが、アプリケーション全体の処理の流れに起因するエラーはトラップのしようが無いからです。これはエラーという用語の定義そのものに関わります。そして、こうしたエラーは例外処理の技術を駆使しても、デバッガを使っても、品質保証部門がどんなに努力しても、取り除く事が出来ません。ここで述べたいのはそうしたエラー、つまり失敗についてです。
失敗にはプログラムの処理を通常の範囲から逸脱させるという側面があります。外部環境や予期しない結果の相互作用がもたらすものであり、対応する何らかの対処をしないと訂正することができません。言いかえると、失敗とは例外のように単純に取り扱えない割り込みであると言えるでしょう。また、どのようにアプリケーションが動作するべきかの判断を人から直接に指示される必要があります。
たとえば、ディスクスペースが不足した場合などは、対処しなければならない問題ですがアプリケーション内部の問題ではありません。同様に、ハードディスクがクラッシュしてセクタがダメージを受けてしまった場合のように、ファイルIOエラーが発生した場合は、アプリケーションの範囲で回復ができる状態ではありません。それよりも、ユーザがそのエラーを確認し、理由を知り、どのようにリカバリを行うかについて指示を与えます。
他の場合としては、デバイスの欠乏の場合が考えられます。アプリケーションがネットワークカードやダイヤルアップのネットワーク接続が必要になったのに資源が利用出来ない場合です。この場合に出来る納得いく解決策はといえば、ユーザにそれを解決してほしいと知らせたり他の方法を提案するくらいです。
プリンタがインストールされていなかったとします。自動的にこの問題を解決しようとしてもアプリケーションの範疇にある問題ではありません。アプリケーションは勝手にプリンタの導入を出来ませんし、どうにかなる対策がなにかあるわけでもありません。これはオペレーティングシステムとハードウェアの問題です。繰り返しますが、デバイスが利用できるようになってからディスクファイルをセーブするとか、他の方法に変更するとかどうするかは、利用者が決めなければなりません。
ポータブルコンピュータにインストールされているあるアプリケーションはドッキングステーションが接続されている場合にだけ利用できるとします。そのアプリケーションがドッキングステーションに接続されていないことを判断したとしても、リカバリはユーザの判断次第であり、出来ることといえば、ユーザに知らせたりどうすれば良いかを表示する事くらいです。
これらの場合、単にエラーを表示するだけでは不充分です。どのように対応するべきかを示す必要が常にあります。
失敗には、システムが結果的に対応するものと、アプリケーション内部のエラーという2種類がオーバーラップしています。ユーザが入力したデータにより0除算になってしまうとか、nullポインタになってしまうとか、nullストリングになってしまうなど、いろいろな形で現れてきます。このような場合は、プログラムが適切に処理しておらず、確認テストからも漏れてしまったことは明らかです。
近視眼的に見れば、ユーザの入力によるエラーは機械命令実行エラーを引き起こしてしまう"すっぽ抜け"に過ぎないわけですが、本当にこのエラーについて責任があるのは、入力時の検査を失敗したアプリケーションの設計者です。優秀なプログラマの言を借りれば、このようなことは(しばしばある事ですが)設計者の能力の欠如を端的に示しています。

・・・・・・


-広告について-

Google
  Web www.calvadoshof.com