役立つエラーメッセージに関する開発者の問題は何ですか？[閉まっている]

今日でも、プロのチームによって構築された、長年使用されてきた製品が、今日までまだ、ユーザーに役立つエラーメッセージを提供できないことに驚かされます。場合によっては、ほんの少しの追加情報を追加するだけで、ユーザーの時間を節約できます。

エラーを生成するプログラムが、何らかの理由で生成しました。何が失敗したのか、ユーザーにできる限り多くの情報を提供するために、すべてを自由に使用できます。それでも、ユーザーを支援する情報を提供することは優先度が低いようです。これは大きな失敗だと思います。

1つの例はSQL Serverからのものです。使用中のデータベースを復元しようとすると、まったく問題が発生します。SQL Serverは、どのプロセスとアプリケーションがそれにアクセスしているかを知っています。データベースを使用しているプロセスに関する情報を含めることができないのはなぜですか？すべての人がApplicatio_Name接続文字列で属性を渡すわけではないことは知っていますが、問題のマシンに関するヒントさえあれば役立つかもしれません。

別の候補であるSQL Server（およびmySQL）は、美しいstring or binary data would be truncatedエラーメッセージと同等のものです。多くの場合、生成されたSQLステートメントの単純な閲覧と、テーブルが原因の列を示します。これは常に当てはまるわけではありません。データベースエンジンがエラーを検出した場合、なぜその時間を節約できず、どの列が壊れているかを教えてくれないのでしょうか。この例では、それをチェックするとパフォーマンスが低下する可能性があり、これがライターを妨げると主張できます。結構です、私はそれを買います。データベースエンジンは、エラーがあることを認識すると、格納される値と列の長さを事後比較します。次に、それをユーザーに表示します。

ASP.NETの恐ろしいテーブルアダプタも有罪です。クエリを実行し、どこかで制約に違反していることを示すエラーメッセージを表示できます。ありがとう。開発者は行番号やサンプルデータを提供するのが面倒なので、データモデルとデータベースを比較する時間です。（記録のために、私は選択によってこのデータアクセス方法を決して使用しませんでした、それはただ私が継承したプロジェクトです！）。

C＃またはC ++コードから例外をスローするたびに、手元にあるすべてのものをユーザーに提供します。それを投げる決定が下されたので、私が提供できる情報が多ければ多いほど良いです。関数が例外をスローしたのはなぜですか？何が渡され、何が期待されましたか？例外メッセージの本文に意味のあるものを入れるには少し時間がかかります。地獄、それは何もしませんが、私のコードは意味のあるものを投げることを知っているので、私が開発する間、私を助けます。

複雑な例外メッセージをユーザーに表示すべきではないと主張することができます。私はそれに反対しますが、それはあなたのビルドに応じて異なるレベルの冗長性を持つことで簡単になだめることができる議論です。それでも、ASP.NETおよびSQL Serverのユーザーは一般的なユーザーではなく、問題をより迅速に追跡できるため、冗長でおいしい情報に満ちたものを好むでしょう。

開発者がエラーが発生したときに最低限の情報を提供することは、この日と年齢で大丈夫だと思うのはなぜですか？

それは2011年の男だ、来るで。

単にあるべきではない悪いエラーメッセージの例はたくさんありますが、見たい情報を常に提供できるとは限らないことを覚えておく必要があります。

あまりにも多くの情報を公開することに対する懸念もあり、開発者は注意を払ってエラーを起こす可能性があります。（しゃれは意図されていなかったと約束しますが、気づいたので削除しません。）

場合によっては、複雑なエラーメッセージがエンドユーザーにとって役に立たないという事実もあります。情報の過負荷でサイディングすることは、エラーメッセージに対して必ずしも良いアプローチではありません。（ログに保存するのが最適かもしれません。）

開発者はエラーメッセージを書くのにふさわしい人ではありません。

彼らはアプリケーションを間違った角度から見ています。彼らは、コード内で何が間違っていたかを非常によく知っていますが、何かを達成しようとする観点からソフトウェアに近づかないことがよくあります。その結果、開発者にとって重要な情報は、ユーザーにとって必ずしも重要な情報ではありません。

慈善の視点：

• 開発者はコードと緊密に連携し、コードの操作に理解がない人を理解するのに苦労しました。その結果、彼らが考えて、彼らはちょうどそれらを判断することで、参照の良いフレームを持っていない、エラーメッセージが細かいです。

• インテリジェントエラーメッセージは実際には実行が困難です。それらを書くだけでなく、間違っている可能性のあるものすべてを解決し、可能性を評価し、メッセージを読んでいる人に有益な情報（ほぼ確実にコンテキストによって異なる）を提供して、修正できるようにする必要があります。

• ほとんどのアプリケーションでは、エラーがそれほど頻繁に発生しないため、次の開発者が本当に望んでいるのと同様に、この種のことを行う時間について良いケースを作ることは困難です。また、余分な時間があった場合は、エラーを報告するのではなく、エラーの停止に費やすべきではありませんか？

変更不可能なビュー：

• エラーメッセージとエラー処理は退屈で、取り組むべきはるかに興味深いものがあり、上司は次のことについて私の背中にいます。私はこのコードを理解しています、私は大丈夫です、次の人は最終的にそれを解決します、そして私はその時までにここから出るので、それは私の問題ではありません。

現実はおそらく中間のどこかにありますが、私の経験では実際には後者よりも前者のほうがはるかに多いと言っています-基本的には実際には非常に難しく、おそらく起こらないことを扱うにはかなりの努力が必要です。

残念ながら、より有用なエラーメッセージは開発者の時間を要します。これは会社のお金に匹敵します。製品は、そのままビルドするのに十分高価です。はい、もっと役立つエラーメッセージがあれば素晴らしいでしょうし、もっと役立つエラーメッセージを含めるべきだということに同意します。しかし、それは人生の事実であり、あなたが期限内にいて、お金が限界にあるとき、あなたは何かを切らなければなりません。「きれいなエラーメッセージ」は、管理者が見るかもしれませんが、おそらく最初に行くことです。

エラーメッセージはできるだけ具体的にする必要があることに同意します。

一般的なエラーメッセージの理由の1つは、おそらくエラーコードの使用です。例外を使用する場合、エラーメッセージで必要なものすべてを自由に渡すことができます。戻りコードを使用すると、列名をエンコードする余地がありません。おそらく、エラーは、コンテキストを知らず、エラーコードを文字列に変換するだけの汎用関数によって処理されます。

• 情報が多すぎるとセキュリティリスクになる場合があります。あなたは誰がエラーメッセージを読んでいるかわからない
• 例外をスローした操作が非常に複雑なため、コードの速度/複雑さに悪影響を与えずに意味のあるメッセージを取得できない場合があります

一般的な通知として、エラーまたは例外的な状況は、まさにそれである例外的であると考えるべきです。計画および設計された手順を横断します。動作するように計画された方法とは互換性がありません。これが当てはまらない場合は、エラーアボートで救済する必要はありません。

私たちプログラマーは、この計画された手順の自己保護に注意するように訓練されています。したがって、仮定を検証するために、定期的にいくつかの健全性チェックを含めます。これらの健全性チェックが失敗すると、計画が何らかの形で失敗したことがわかります...

そのようなシステムがどのように機能するかの現実を考慮すると、ユーザーの観点からは、ユーザーの観点からは常識のように見えるかもしれませんが、それを実現することは不可能です。整然とした適切な情報を追加した整然とした声明を求めます。さらに、このプレゼンテーションは、一般的なアプリケーション/処理設計に適合する方法で行われることを要求します。明らかに、この情報はシステムのどこかに存在します。明らかにそれは整然とうまく組織化された方法でそこに存在します（そうすることを望みます）。しかし、エラーが発生した時点で、この情報を利用できるようにする予定はありません。エラーは常に制御の部分的な喪失です。この制御の喪失は、さまざまなレベルで発生する可能性があります。実行時のシステムの動作が計画と異なる場合があります。しかし、実際の実装は計画よりもはるかに難しく、詳細が異なることが判明した可能性があり、この状況を満足に処理するための余裕のある規定はありませんでした。これも制御の部分的な喪失です。

これを指定した具体的な例に関連付けるには、エラーの時点で、テーブル列の名前とタイプ、さらに必要なスペースの長さがわかっていれば、理由はありません。エラーが発生しませんか？状況を修正して、計画どおりに進めることができます。エラーが発生することを余儀なくされているという事実は、問題が紛失したことを示しています。これらの情報が手元にないというまさに事実は例外です。

ここで書いていることは、自明であり、単なる常識のように思えるかもしれません。しかし、実際には把握するのは非常に困難です。私たちは常に道徳的なカテゴリーを適用することでそれを理解しようとします -犯人がいるに違いない、貧しいユーザーを気にしない悪い怠け者がいるにちがいない、安価な計算の方法を行った貪欲なビジネスマンがいるに違いない これはすべて、ポイント以外の完全なものです

コントロールを失う可能性は、私たちが計画的で規則正しいやり方で物事をしているというまさに事実から生じます。

私はソフトウェア会社のサポートエンジニアとして働いていますが、よくあるエラーメッセージが表示されます。これらを開発チームに紹介する際に、アプリケーションのソースでメッセージを検索する必要がよくあります。

ユーザーに提示されていなくても、開発チームが新しいものを追加するたびにエラーメッセージインデックスのドキュメントまたはデータベースにメモを追加すると、私たちにとってはかなり安全だと思われます顧客の問題の原因を見つけて時間を節約するために、はるかに迅速に...

そこに見られる問題は、適切なカプセル化と情報隠蔽の副作用の1つです。

現代のシステムは非常に複雑です。平均的な開発者が、特定のタスクをコーディングしている間、UIから生のバイナリまでのシステム全体のメンタルモデルを頭の中で保持できる可能性はほとんどありません。

したがって、開発者が座って、たとえばデータベースファイルを復元するビットをコーディングしている間、彼のメンタルモデルは、データベースファイルを復元する行為を取り巻くビットで完全に満たされます。彼は、ファイルの読み取り、プロパティの確認、バージョンの読み取り、既存のデータのバックアップ、マージ/上書き戦略の選択などを行う必要があります（このコードを書いていないと思います）。 UIを考慮して、例外ハンドラーに書き込むエラー文字列に含まれます。何かのようなもの：

catch (IOException error)
{
//File is in use
throw new GenericExceptionParsedByTheUIThread("File is in use.");
}

この例では、ファイルまたはDB内の他のスレッドを使用している可能性のあるプロセスに関して尋ねている有益な情報は、完全に（プログラム的に）範囲外です。DBファイルを処理するクラスが数百ある場合があります。ファイルを使用して他のすべてのプロセスに関する情報をファイルにインポートするか、ファイルシステムにアクセスして実行中の他のプロセスを調べる機能（これらのプロセスがTHISマシン上にあると仮定）は、リーキーアブストラクションと呼ばれるものになります。生産性に直接的なコストがかかります。

そのため、現代ではこのようなエラーが持続する可能性があります。明らかに、それらはすべて修正できました。しかし、多くの場合、考えられるよりもはるかに多くのオーバーヘッドがあります（この場合、たとえば、この関数がネットワーク接続と共有の列挙を走査して、リモートマシンがこのデータベースファイルを使用しているかどうかを確認する必要があります理由）そして費用は些細なことからほど遠い。

私のお気に入りは（70年代後半に）ユニバックFortran IVコンパイラでした。

意味のないデータの解釈が試みられました

エラーメッセージの大部分は、実際にはプログラマー（自己）向けの栄光に満ちたデバッグコード/ printfステートメントであると思います。

ユーザー指向のエラーメッセージを作成するということは、ユーザーが誰であるかを知り、知りたいことを予測することを意味します。開発者は、コードを記述している最中に、現在書いているコードをデバッグするため、または既知または主なユースケースに役立つ、自分自身に役立つエラーメッセージを書く傾向があります。

コードの記述からユーザーインターフェイス（またはユーザーエクスペリエンス）のテキスト部分の設計への切り替えは、コンテキストスイッチです。多言語アプリケーションなどの大規模アプリケーションでは、開発者が完全に処理するのではなく、別の人またはチーム（UI、翻訳）に引き継がれる可能性があるため、開発者がメッセージのコンテキストを慎重に説明しない限り、重要な詳細は簡単に失われました。

もちろん、エラーと例外が処理される（つまり、キャッチされる）限り、エラー処理のチェックと検証は優先度が低いと見なされますが、それほど重視されません。エラー状態には多くの場合、否定的な意味合い（つまり、間違いや失敗）が関連付けられているため、開発者またはQAが評価するためのコードベースの精神的に不利な場所です。

その理由は、エラーの報告/処理が常に後から考えられるからだと思います。彼らが完全に考えた後ではない場合でも、彼らはほとんど全体的なデザインの二流の市民です。

最近のソフトウェアは通常、複数のレイヤーで構成されています。エラー報告ロジックをあまり考えずに急いで作成すると、有用なエラーメッセージを表示するために必要なすべての情報を収集することが困難になることがよくあります。

たとえば、エラーはバックエンドでキャッチされますが、包括的なエラーメッセージを作成するには上位層からの情報が必要です。最も良いエラーメッセージには、ほとんどすべての層からの情報が必要です（システムで発生したことの包括的なビューを提供するため）。理想的なエラーメッセージは、「OK、最初に文字列を受け取ってから、おかしなものを与えるパーサーを通過したので、見たいと思うかもしれません。とにかく、それはさらに下に渡されました...」

設計段階でエラー報告メカニズムが第一級市民でない場合、それを行うには不必要な結合が必要になることがよくあります。ほとんどの人は、見た目が良くないもの（「参照してください。私のプログラムがクラッシュしました。エラーメッセージは便利です！」