エラーには大抵「エラーメッセージ」が付いています。 自分は過去に、エラーメッセージの内容を雑にしてしまい後悔することがよくありました。 その経験から、良いエラーメッセージの書き方を考えました。 エラーメッセージを2つに分類する まず、エラーメッセージといっても次の2つのパターンで大きく異なってきます。 (1) ユーザーが見るエラーメッセージ (2) 開発者が見るエラーメッセージ (1) ユーザーが見るエラーメッセージ 内部実装のことは書かないようにする
システムのエラー処理を総合的に設計する どんなシステムでもエラー処理は欠かせず、たいていは大きな割合を占める。システム上のエラーはもちろん、業務上に代表される問題領域のエラーまで対応しなければならないからだ。エラー処理の基本は、エラーを検出し、その結果によって適切な処理を実行すること。しかし、システム全体でみれば、異なるタイプのエラーが数多くあるため、エラー処理が分散するし、エラーの種類ごとに対処が違う。完成度の高いシステムを目指すなら、全部のエラーを把握しながら、システムを設計する必要がある。 一部のエラー処理は、システムの基本構造と深く関係している。エラー処理を重視すると、システムの基本構造に影響を与える。逆に、システムの基本構造がエラー処理の一部を制限することもある。仕方がないので、両者の妥協点を見付けるしかない。 この点を考慮し、次のような手順で基本構造を設計する。最初は、エラーが
ユーザにとってエラーの対応はプログラムの品質(完成度)を印象付ける大事な要素になります。 エラー処理が無いプログラムは無いと思いますが、大きなプロジェクト以外では暗黙の対応が多いように思います。暗黙の対応とは、製造時にプログラマーがエラー処理を追加していくことです。 この場合は、システムによりエラーの対処方がまちまちで処理の抜けや製造後に追加した為にソースコードの可読性が落ち保守性が悪くなります。保守工数を減らす為にもエラー処理を設計する必要があります。 エラー処理は、システム上のエラーのほかに、業務上の問題やユーザの操作ミスなどを抑制するように処理を設計します。このため、基本設計段階で大局的な観点からエラー処理を設計します。 エラー設計項目
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く