基本
- わかりやすく、そして端的に
- ユーザが必要な情報だけを伝える(関数名なんていらない)
- Primary, Detail, Hintのレベルで分ける(主題(結論)、詳細(内訳とか)、ヒント(修正方法))。
よーく考えよう。
「未知の~です」「Unknwon ...」
アプリケーションにとって、未知であることは確かにエラーだろう。
だけど、ユーザーにとってそうではない。
たとえば、「未対応の」や「非対応の」、「無効な」などのエラーのほうが幾分マシである。
英語の意味
ファイルを開けません
- could not open file HOGEHOGE
- ファイルを開けなかった。存在していないファイルか指定されたときなど。今後、回復される見込みがある。ある意味で物理的な問題。
- cannot open file HOGEHOGE
- そもそも対応していないファイルだった場合。ある意味で論理的な問題。今後、回復される見込みはない(バージョンアップは別)。
参考文献
ダメな例
エラーコード
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__)