タグ付けされた質問 「error-messages」

私の家族の友人が、プログラミング（C言語）を学ぶときに少し助けを求めました。私たちが話していたとき、彼はコンパイラー（GCC）がエラーを起こしたときに彼に与えるエラーメッセージを理解するのに苦労していることにフラストレーションを表明しました。彼は、使用されているすべての用語を理解していません。また、それらの組み合わせが理解できない場合もあります。「コンパイラのドキュメントに、エラーメッセージの詳細な説明が含まれていないのはなぜですか？」-そして、私は彼に良い答えがありませんでした。 私自身-より経験豊富なプログラマーとして-この状況ではめったにありませんが、これらのまれな出来事は起こります-私が以前に遭遇したことのないいくつかのエキゾチックなエラーメッセージ。私は検索エンジンでエラーメッセージを探すことで何とかやっていくことができますが、どうやらそれは彼のために常に機能するとは限りません-特に彼が遭遇するエラーはより一般的であり、彼が彼に関連するトラブルを抱えている複数の異なるケースで発生するため自分の。 それでは、初心者プログラマはコンパイラエラーメッセージを理解するという課題にどのように取り組むべきでしょうか？具体的には、CとGCCの組み合わせで？

66 compilation  error-messages  training  gcc 

バグを見つけるための一般的なパターンは、このスクリプトに従います。 たとえば、出力がない、プログラムがハングしているなど、奇妙な点を観察してください。 ログまたはプログラム出力で関連するメッセージを見つけます。たとえば、「Fooが見つかりませんでした」。（以下は、これがバグを見つけるためのパスである場合にのみ関連します。スタックトレースまたは他のデバッグ情報がすぐに利用できる場合は、別の話です。） メッセージが印刷されるコードを見つけます。 Fooが画像を最初に入力する（または入力する必要のある）場所と、メッセージが印刷される場所の間でコードをデバッグします。 この3番目のステップでは、コード内に「Coo not find Foo」（またはテンプレート化された文字列Could not find {name}）が印刷される場所が多くあるため、デバッグプロセスが停止することがよくあります。実際、スペルミスが何度かあったとすると、実際の場所を見つけるのに非常に速くなりました。システム全体で、そして多くの場合世界中でメッセージが一意になり、関連する検索エンジンがすぐにヒットしました。 これから明らかな結論は、コード内でグローバルに一意のメッセージIDを使用し、メッセージ文字列の一部としてハードコーディングし、コードベース内に各IDが1つしか存在しないことを検証する必要があるということです。保守性の観点から、このコミュニティはこのアプローチの最も重要な長所と短所をどのように考えていますか？これをどのように実装するか、そうでなければ実装が必要にならないことを保証しますか？（ソフトウェアには常にバグがあると仮定して）

39 design-patterns  logging  error-messages 

アプリケーションは常にエラーをスローできます。このようなエラーが発生した場合、ユーザーにアプリケーションに要求したことが成功しなかったため、ユーザーに通知する必要があります。 ただし、ユーザーにはどの程度の情報を提供する必要がありますか？私たちのほとんどは、スタックトレースを表示しないことに同意すると思います（スタックトレースは、ユーザーに表示されるエラーメッセージに含まれるべきですか？）ユーザー。 たとえば、例外をサポートする言語（.net、java）には、共有する例外の種類、例外が発生した場所、および例外に沿った明確なメッセージがあります。これもユーザーに非表示にする必要がありますか？または、とにかくこれを表示する必要がありますか？または、一般的なメッセージを表示する必要がありますか？または、基になる例外が何であるかに基づいて、いくつかのメッセージの1つを表示する必要がありますか？

38 user-interface  error-handling  user-experience  error-messages  information-presentation 

プログラミングするとき、時々物事が壊れます。間違いを犯し、プログラムが間違ったアドレスから読み取ろうとしています。 多くの場合、これらの例外は次のようなものであることを私に際立たせます： Access violation at address 012D37BC in module 'myprog.exe'. Read of address 0000000C. 今、私は多くのエラーログを見て、私にとって際立っているのは、0000000Cです。これは「特別な」住所ですか？不正な読み取りを伴う他のアクセス違反が表示されますが、アドレスはランダムに見えますが、これはまったく異なる状況で繰り返し表示されます。

32 windows  error-handling  error-messages 

あなたはそれらを知っています、意味をなさないエラー。グレムリンがチップの奥深くに飛び込んで、何かを台無しにしたように思えます。散歩して、物を書いて、おじさんに電話しますか？

29 productivity  debugging  error-handling  motivation  error-messages 

今日でも、プロのチームによって構築された、長年使用されてきた製品が、今日までまだ、ユーザーに役立つエラーメッセージを提供できないことに驚かされます。場合によっては、ほんの少しの追加情報を追加するだけで、ユーザーの時間を節約できます。 エラーを生成するプログラムが、何らかの理由で生成しました。何が失敗したのか、ユーザーにできる限り多くの情報を提供するために、すべてを自由に使用できます。それでも、ユーザーを支援する情報を提供することは優先度が低いようです。これは大きな失敗だと思います。 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年の男だ、来るで。

29 design  exceptions  error-messages 

C ++テンプレートは、読み取り不能な長いエラーメッセージを生成することで有名です。C ++のテンプレートエラーメッセージがなぜそんなに悪いのかについての一般的な考えがあります。基本的に、問題はコンパイラーがテンプレート内の特定の型でサポートされていない構文に遭遇するまでエラーがトリガーされないことです。例えば： template <class T> void dosomething(T& x) { x += 5; } 演算子がTサポートされていない場合+=、コンパイラはエラーメッセージを生成します。そして、これがどこかライブラリの奥深くで発生した場合、エラーメッセージは数千行に及ぶ可能性があります。 ただし、C ++テンプレートは基本的に、コンパイル時のダックタイピングのメカニズムにすぎません。C ++テンプレートエラーは、Pythonなどの動的言語で発生する可能性のあるランタイムタイプエラーに概念的に非常に似ています。たとえば、次のPythonコードを考えます。 def dosomething(x): x.foo() ここでx、foo()メソッドがない場合、Pythonインタープリターは例外をスローし、問題を示す非常に明確なエラーメッセージとともにスタックトレースを表示します。インタプリタが何らかのライブラリ関数の奥深くになるまでエラーがトリガーされない場合でも、ランタイムエラーメッセージは、典型的なC ++コンパイラによって吐き出される読み取り不能な嘔吐物ほど悪いものではありません。それでは、なぜC ++コンパイラが何が問題なのかをより明確にできないのでしょうか？一部のC ++テンプレートエラーメッセージにより、文字どおり、コンソールウィンドウが5秒以上スクロールするのはなぜですか？

28 c++  python  templates  error-messages 

stackoverflowでは、この問題が常に発生します： E_NOTICE？== E_DEBUG、より洗練されたerror_handlerでisset（）および@を回避 E_NOTICEがオンのときに$ _GETのundefindインデックスをチェックしないようにPHPを設定する方法は？ PHPがPHP Noticeエラーを記録しないようにする方法 このようなPHP 5.3通知をオフにするにはどうすればよいですか？ でもペッカ（固体PHPのアドバイスの多くを提供しています）恐ろしい突き当てたE_NOTICEモンスターと望んで使用するよりも、よりよい解決策のためにisset()：ISSET（）と醜い空（）メイクコード 個人的には、アプリケーションのフローを管理するために多くの場所で使用isset()しempty()ています。例えば： public function do_something($optional_parameter = NULL) { if (!empty($optional_parameter)) { // do optional stuff with the contents of $optional_parameter } // do mandatory stuff } このような単純なスニペットでも： if (!isset($_REQUEST['form_var'])) { // something's missing, do something about it. } 私には非常に理にかなっています。肥大化しているようには見えず、安定したコードのように見えます。しかし、多くの開発者はをE_NOTICE有効にしてアプリケーションを起動し、多くのフラストレーションのある「初期化されていない配列インデックス」通知を発見し、定義済み変数をチェックしてコードを「ポイ捨て」する見込みに顔をしかめますisset()。 他の言語は物事を異なる方法で処理すると思います。経験から言えば、JavaScriptはPHPほど丁寧ではありません。未定義の変数は、通常、スクリプトの実行を停止します。また、（経験不足から言えば）C / …

27 php  error-messages 

私たちは皆これを見たと思います。初心者は、基本的な概要に従うStack Overflowで質問をします... 私はやろうとしています（目標の非常に漠然とした説明）がうまくいきません/エラー/例外が発生します。助けてください！ 彼らの多くがエラーメッセージを貼り付ける必要がないと考えるのは奇妙ではないでしょうか？ これの心理学は何だろうか。人々が最初は役に立たず、注意を払う価値がないと思わせるエラーメッセージについてはどうですか？ 私が探している答えは、「彼らはエラーメッセージを理解していません」ではありません。それは、彼らがそれを理解するかもしれない他の誰かに話すことを考慮しない理由を説明しません。

27 debugging  junior-programmer  error-messages 

CおよびC ++コンパイラがエラーから回復して解析を続行しようとする理由を理解できませんでした。ほとんどの場合、最初のエラーは偽のエラーのストリームを生成し、最初のエラーが修正されるとすぐに消えます。数年の経験の後、私はすべてのファイルの最初のエラー以外のエラーを見ることを止めました。コンパイラを再実行し、エラーがなくなるまでもう一度実行します。それは一般的な習慣ですか？

19 c++  c  error-messages  compiler 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 エラーメッセージで感嘆符を使用することについてどう思いますか？すなわち、「アドレスが無効です！」。 個人的には、それは何も追加せず、ユーザーをin辱し、製品が12歳のTRS-80 BASICで書かれたように見えると思います。

13 error-messages 

中規模のプロジェクトを開発する際に、エラーコードを特定、作成、および維持する方法を教えてください。 私の人生では、そうするためのシンプルでクリーンな方法を考えることはできません。私のアイデアのいくつかはクラス名とメソッド名を整数文字列に変換しますが、それはメソッド名とクラス名が変更される可能性があるという事実の上にユーザーに表示するのに長い道のりです（うまくいけない！）その他は、増分ログシステムを使用しているだけです（つまり、新しいエラーメッセージを作成するたびに、最後のエラーメッセージIDに1を追加するだけです）。しかし、それはまったく組織化されていません。 具体的には、次のようなエラーコードについて説明します。 Error 401 Unauthorized.

13 error-messages 

テキストファイルに対して何かを行うスクリプトを書いています（ただし、それは私の質問とは無関係です）。そのため、ファイルに何かを行う前に、ファイルが存在するかどうかを確認します。私はこれを行うことができますが、問題はありませんが、問題は美学の問題です。 これは、同じことを2つの異なる方法で実装する私のコードです。 def modify_file(filename): assert os.path.isfile(filename), 'file does NOT exist.' Traceback (most recent call last): File "clean_files.py", line 15, in <module> print(clean_file('tes3t.txt')) File "clean_files.py", line 8, in clean_file assert os.path.isfile(filename), 'file does NOT exist.' AssertionError: file does NOT exist. または： def modify_file(filename): if not os.path.isfile(filename): return 'file does NOT exist.' …

12 python  error-handling  error-messages  assertions 

外部の開発者が使用している商用ライブラリとコード例を作成します。ライブラリの使用方法を広範囲に説明する（登録済みユーザーは利用できますが、閉鎖された）ドキュメントがあります。 開発者の多くは初めてのユーザーなので、多くの初歩的なエラーが発生します。 エラーログにドキュメントへのリンクを含めることは適切ですか？考えられる欠点は何ですか？いくつかは予想できますが、以下を克服することは可能と思われます ドキュメントのURLが古い 最新のドキュメントに反映されていないバージョン固有のエラー 他に何か問題があり、無関係なドキュメントに送信することで開発者の時間を無駄にしています 意味の例の下に、太字のテキストを追加するのは良い考えですか？ [エラー]プロジェクトstandalone-pomで目標org.apache.maven.plugins：maven-archetype-plugin：1.2.3：generate（default-cli）を実行できませんでした：目的のアーキタイプが存在しません（com.example.library。 archetypes：library-archetype-blank：1.2.3.0）->詳細および考えられるトラブルシューティングについては、http：//example.com/docs/setting-up-an-archetypeを参照してください

10 documentation  api-design  error-handling  error-messages