エラーメッセージ スタイル ガイド

基本

• わかりやすく、そして端的に
• ユーザが必要な情報だけを伝える（関数名なんていらない）
• Primary, Detail, Hintのレベルで分ける（主題（結論）、詳細（内訳とか）、ヒント（修正方法））。

よーく考えよう。

「未知の～です」「Unknwon ...」

アプリケーションにとって、未知であることは確かにエラーだろう。
だけど、ユーザーにとってそうではない。
たとえば、「未対応の」や「非対応の」、「無効な」などのエラーのほうが幾分マシである。

英語の意味

ファイルを開けません

could not open file HOGEHOGE

ファイルを開けなかった。存在していないファイルか指定されたときなど。今後、回復される見込みがある。ある意味で物理的な問題。

cannot open file HOGEHOGE

そもそも対応していないファイルだった場合。ある意味で論理的な問題。今後、回復される見込みはない（バージョンアップは別）。

参考文献

1. 参考文献「エラーメッセージのスタイルガイド
2. 参考文献「FPN-文章を短く分かりやすく書くには」
3. http://en.wikipedia.org/wiki/Error_message

ダメな例

• http://homepage.mac.com/bradster/iarchitect/errormsg.htm

エラーコード

GDCで聞いた話題。

　次に信頼できるエラーハンドリングについて。

　「期待外のエラーを検出しました。」と表示されてわかるのは、

なにか悪いことが起こったことだけで、何が起こったかわからない？！？

どんなカスタマーサポートをすればいい？オペレーションチームは何をすればいい？

「リブートしてください」？

　エラーのログをとろう。

　でも誰がログを読むの？どんなエラーログがいい？

　・悪い例：Resource not found 404!

　　→HTTPエラーコードをゲームエラーとして使ってはいけない。

　・より良い例：Fancy message with *link* 34-15-3-743

　　→「*link*」は、あなたの会社のサポートサイトやウィキページです。

　　→数字の意味は、下記の通り。

　　　 34: Error code : (routing error)

　　　 15: Service number : (cache server)

　　　 3: Module number : (forwarder.cpp)

　　　743: Line number : (__LINE__)