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

私はしばらくこの問題を熟考してきましたが、絶えず警告や矛盾を見つけているので、誰かが次の結論を出すことを望んでいます。 エラーコードよりも例外を優先する 私が知っている限りでは、業界で4年間働いて、本やブログなどを読んでから、エラーを処理するための現在のベストプラクティスは、エラーコード（必ずしもエラーコードではなく、エラーを表すタイプ）。 しかし-私にはこれは矛盾しているようです... 実装ではなく、インターフェースへのコーディング 結合を減らすために、インターフェイスまたは抽象化にコーディングします。インターフェースの特定のタイプと実装を知りませんし、知りたくありません。では、どの例外をキャッチする必要があるのか​​をどのようにして知ることができますか？実装は10種類の例外をスローすることも、何もスローしないこともあります。例外を確実にキャッチするとき、実装について仮定しているのでしょうか？ 場合を除き-インターフェイスが持っています... 例外仕様 一部の言語では、開発者は特定のメソッドが特定の例外をスローすることを宣言できます（たとえば、Javaはthrowsキーワードを使用します）。 しかし-これは...を示唆しているようです 漏れやすい抽象化 インターフェイスでスローできる例外を指定する必要があるのはなぜですか？実装が例外をスローする必要がない場合、または他の例外をスローする必要がある場合はどうなりますか？インターフェイスレベルでは、実装がスローする例外を知る方法はありません。 そう... 結論する ソフトウェアのベストプラクティスに矛盾するように見える（私の目には）のに、なぜ例外が優先されるのですか？また、エラーコードが非常に悪い場合（およびエラーコードの悪徳で販売する必要がない場合）、別の選択肢がありますか？上記のベストプラクティスの要件を満たしているが、エラーコードの戻り値をチェックする呼び出しコードに依存しない、エラー処理の現在の（またはまもなく）技術の現状は何ですか？

118 design  language-agnostic  error-handling 

この質問は馬鹿げているように聞こえるかもしれませんが、ほとんどのプログラミング言語が0評価されfalse、他の[整数]値が評価されるのはなぜtrueですか？ 文字列比較 質問は少し単純すぎるように思えるので、もう少し説明します。まず、プログラマーにとっては明白に思えるかもしれませんが、なぜプログラミング言語がないのか-実際にはあるかもしれませんが、私は使用しました-どこに0評価しtrue、他のすべての[整数]値を評価しfalseますか？その発言はランダムに見えるかもしれませんが、私はそれが良いアイデアだったかもしれないいくつかの例を持っています。まず、文字列の3者間比較の例を取り上げましょstrcmpう。Cを例に取ります。C 言語を最初の言語として試すプログラマーは、次のコードを書きたくなるかもしれません。 if (strcmp(str1, str2)) { // Do something... } 文字列が等しいときに評価されるstrcmp戻り値なので、最初のプログラマーがやろうとしたことは惨めに失敗し、一般的に最初はなぜか理解できません。していたために評価上記1 - -代わりに、この関数はその最も単純な式で使用されている可能性が平等を比較するとき、およびのための適切なチェックとは、必要なときにのみ行われていたであろう。ほとんどの場合、戻り値の型を（私たちの考えでは）考えていたでしょう。0false0true-11bool さらに、sign値-1、0およびのみを受け取る新しいタイプを導入しましょう1。それはかなり便利です。C ++に宇宙船オペレーターがあり、それを望んでいると想像してくださいstd::string（まあ、既にcompare関数はありますが、宇宙船オペレーターはもっと楽しいです）。現在、宣言は次のようになります。 sign operator<=>(const std::string& lhs, const std::string& rhs); していた0ために評価されtrue、宇宙船演算子は存在さえしないだろう、と私たちは宣言している可能性がoperator==そのように： sign operator==(const std::string& lhs, const std::string& rhs); これoperator==は3者間比較を一度に処理し、必要に応じてどの文字列が辞書的に優れているかを確認しながら、次のチェックを実行するために使用できます。 if (str1 == str2) { // Do something... } 古いエラー処理 現在、例外があるため、この部分は、そのようなものが存在しない古い言語（Cなど）にのみ適用されます。Cの標準ライブラリ（およびPOSIXのライブラリ）を見ると、maaaaany関数0が成功すると必ず戻り、それ以外の整数は必ず戻ります。悲しいことに、このようなことをする人を見たことがあります。 #define TRUE 0 // ... if …

115 language-design  history  error-handling 

先週、アプリケーションのサービスレイヤーでnullを処理することについて、激しい議論がありました。問題は.NETコンテキストにありますが、Javaや他の多くのテクノロジーでも同じです。 問題は、nullを常にチェックし、何があってもコードを動作させるか、nullが予期せず受信されたときに例外を発生させるか、ということでした。 一方で、nullを期待していない（つまり、それを処理するユーザーインターフェイスがない）ところをチェックすることは、catchを空にしてtryブロックを記述することと同じです。エラーを隠しているだけです。エラーは、コード内で何かが変更され、nullが予期される値になったこと、または他のエラーがあり、間違ったIDがメソッドに渡されたことが考えられます。 一方、nullをチェックすることは一般的に良い習慣です。さらに、チェックがある場合、アプリケーションが機能し続ける可能性がありますが、機能のごく一部が効果を発揮しません。次に、「ページXを開くことができない」などのより深刻なバグの代わりに、「コメントを削除できない」などの小さなバグを報告する場合があります。 あなたはどのような慣習に従い、どちらのアプローチに対して賛成または反対ですか？ 更新： 特定のケースに関する詳細を追加します。データベースからいくつかのオブジェクトを取得し、それらに対して何らかの処理を行いました（たとえば、コレクションを構築します）。コードを記述した開発者は、オブジェクトがnullになる可能性があることを予期していなかったため、チェックを含めず、ページが読み込まれたときにエラーが発生し、ページ全体が読み込まれませんでした。 明らかに、この場合はチェックが必要でした。次に、処理されるすべてのオブジェクトを、欠落していることが予想されない場合でもチェックする必要があるかどうか、および最終的な処理をサイレントに中止するかどうかについて議論しました。 仮想的な利点は、ページが引き続き機能することです。Stack Exchangeのさまざまなグループ（ユーザー、コメント、質問）の検索結果を考えてください。メソッドはnullをチェックし、ユーザーの処理を中止できます（バグがnullのため）が、「comments」および「questions」セクションを返します。「ユーザー」セクションが欠落することを除いて、ページは引き続き機能します（これはバグです）。早期に失敗してページ全体を壊すか、作業を続けて「ユーザー」セクションが欠落していることに誰かが気付くのを待つべきでしょうか？

113 error-handling  null 

ここでの私の具体的なケースは、ユーザーがアプリケーションに文字列を渡すことができ、アプリケーションがそれを解析し、構造化オブジェクトに割り当てることです。ユーザーが無効なものを入力する場合があります。例えば、彼らの入力は人を説明するかもしれませんが、彼らは彼らの年齢が「リンゴ」であると言うかもしれません。その場合の正しい動作は、トランザクションをロールバックし、エラーが発生したことをユーザーに伝えることであり、ユーザーは再試行する必要があります。最初のエラーだけでなく、入力で見つかったすべてのエラーについてレポートする必要があるかもしれません。 この場合、例外をスローする必要があると主張しました。彼は、「例外は例外であるべきだ。ユーザーが無効なデータを入力する可能性があるため、これは例外的なケースではない」と言って同意しませんでした。正しいようです。 しかし、そもそも例外が発明されたのはこのためだと私は理解しています。それはあなたがために使用いたエラーが発生したかどうかを確認するために、結果を検査します。チェックに失敗すると、気付かないうちに悪いことが起こる可能性があります。 例外なく、スタックのすべてのレベルが呼び出すメソッドの結果を確認する必要があり、プログラマーがこれらのレベルのいずれかをチェックインするのを忘れると、コードが誤って続行して無効なデータを保存する可能性があります（たとえば）。そのようになりやすいエラーのようです。 とにかく、ここで言ったことは何でも修正してください。私の主な質問は、例外が例外的であるべきだと誰かが言った場合、私の事例が例外的であるかどうかをどのように知ることができますか？

99 java  language-design  exceptions  error-handling 

私のプロジェクトは、単体テストを可能にするほど十分に分離されていると思います。しかし、単体テストを価値のあるものにするために、プロジェクトは、正確に、クラスと機能の面でどれだけ大きくする必要がありますか？ 私たちは皆、間違いを犯し、完璧な人はいませんが、小さなプロジェクトのエラーをステップスルーで処理するための自分はまともなプログラマだと思います。または、プロジェクトのサイズに関係なく、単体テストは非常に必要ですか？

86 project-management  programming-practices  unit-testing  error-handling 

クラスライブラリのメソッドまたはプロパティを記述する必要が生じることがありますが、実際の答えがなくても失敗することは例外ではありません。何かを判断できない、利用できない、見つからない、現在不可能、または利用可能なデータがもうない。 このような比較的例外的ではない状況で、C＃4の失敗を示す3つの解決策があると思います。 そうでなければ意味のないマジック値を返します（nullandなど-1）。 例外をスローします（例KeyNotFoundException）。 パラメータでfalse実際の戻り値を返し、提供しoutます（などDictionary<,>.TryGetValue）。 質問は次のとおりです。どの例外ではない状況で例外をスローする必要がありますか？そして、私が投げてはいけない場合：パラメータ付きのメソッドを実装する上で与えられた魔法の値を返すのはいつTry*outですか？（私にはoutパラメーターが汚れているようで、適切に使用するのはより手間がかかります。） 設計ガイドライン（Try*メソッドについては何も知りません）、使いやすさ（クラスライブラリを求めて）、BCLとの整合性、読みやすさなどの事実に関する答えを探しています。 .NET Framework基本クラスライブラリでは、3つのメソッドすべてが使用されます。 そうでなければ意味のないマジック値を返します。 Collection<T>.IndexOf -1を返します StreamReader.Read -1を返します Math.Sqrt NaNを返します。 Hashtable.Item nullを返します。 例外を投げる： Dictionary<,>.Item KeyNotFoundExceptionをスローします。 Double.ParseFormatExceptionをスローします。または パラメータfalseで実際の戻り値を返し、提供しoutます。 Dictionary<,>.TryGetValue、 Double.TryParse。 HashtableC＃にジェネリックがなかったときに作成されたように、それが使用され、objectしたがってnullマジック値として返されることに注意してください。しかし、ジェネリックでは、で例外が使用されてDictionary<,>おり、当初はありませんでしたTryGetValue。どうやら洞察が変わります。 明らかに、Item- TryGetValueとParse-のTryParse二重性は理由があるので、非例外的な障害に対して例外をスローすることはC＃4で行われていないと思います。ただし、Try*メソッドが存在した場合でも、常に存在するとは限りませんでしDictionary<,>.Itemた。

83 c#  .net  exceptions  error-handling 

javascriptにtry-catchブロックの規定があります。Javaやその他の言語ではエラー処理が必須ですが、JavaScriptでエラーを使用している人は誰もいません。それは良い習慣ではありませんか、それとも私たちはJavaScriptでそれらを必要としませんか？

69 javascript  error-handling 

私は、いくつかのビジネス要件を解決するために新しいプログラミング言語を開発していますが、この言語は初心者ユーザーを対象としています。そのため、言語には例外処理のサポートがなく、追加しても例外を使用するとは思われません。 私は除算演算子を実装しなければならないポイントに達しましたが、ゼロ除算エラーを最適に処理する方法を疑問に思っていますか？ このケースを処理する方法は3つしかありません。 エラーを無視し0て、結果として生成します。可能であれば警告を記録します。 NaN数値の可能な値として追加しNaNますが、言語の他の領域の値を処理する方法についての質問が発生します。 プログラムの実行を終了し、重大なエラーが発生したことをユーザーに報告します。 オプション＃1が唯一の妥当な解決策のようです。オプション＃3は、この言語を使用してロジックを夜間のcronとして実行するため、実用的ではありません。 ゼロ除算エラーを処理するための私の代替手段は何ですか？また、オプション＃1を使用する場合のリスクは何ですか？

62 programming-languages  error-handling 

優れたプログラマーとして、プログラムのすべての結果を処理する堅牢なコードを作成する必要があります。ただし、エラーが発生すると、Cライブラリのほとんどすべての関数は0、-1、またはNULLを返します。 たとえば、ファイルを開こうとするときなど、エラーチェックが必要であることは明らかです。しかし、私はしばしば、printfまたはmalloc必要だと感じないからといって、関数のエラーチェックを無視します。 if(fprintf(stderr, "%s", errMsg) < 0){ perror("An error occurred while displaying the previous error."); exit(1); } 特定のエラーを無視するのは良い習慣ですか、それともすべてのエラーを処理するより良い方法がありますか？

60 c  error-handling 

我々はすべて知っ0/0ているUndefinedと私は電卓にそれを入れていた場合はエラーを返し、私はプログラムを作成した場合、私はゼロによる除算しようとすると、（Cで少なくとも）OSは、それを終了します。 しかし、私が考えていたのは、コンピューターがゼロで除算しようとするのか、それとも「組み込みの保護」があるだけなのか、それ0/0を計算しようとする前でもエラーを返すのですか？

59 math  error-handling  arithmetic 

私が扱ったいくつかのサーバーは、クライアントが失敗と見なすべきリクエストに対してHTTP 200を返します。本文には「success：false」のようなものが含まれます。 これは、特に認証に失敗した場合、HTTPコードの適切な実装とは思えません。「4xx」は変更するまでリクエストを再度行うべきではないことを示し、「5xx」はリクエストが有効または無効であり、再試行できるが失敗したことを示すため、HTTPエラーコードを簡潔に要約しました。この場合、200：ログインに失敗した、または200：そのファイルが見つからなかった、または200：パラメータxが見つからない、間違いが間違っているようです。 一方、「4xx」はリクエストの構造的な問題を示すだけであるという議論が行われていることがわかりました。したがって、200を返すのは適切です。401不正ではなく、不正なユーザー/パスワードは、クライアントが要求を行うことを許可されているためです。この引数は、サーバーが要求を処理して決定を行うことができた場合、応答コードは200である必要があり、詳細については本文を確認するのはクライアント次第であると要約できます。 基本的に、これは好みの問題のようです。しかし、それは満足のいくものではないので、これらのパラダイムのいずれかがより正しい理由が誰かにあるなら、私は知りたいです。

54 http  server  error-handling  client-server 

隠されたAJAXリクエストとは何ですか？ ユーザーのアクションがすぐに発生するように見えるように設計された非表示のAJAXリクエストの使用が増加していることに気付きました。このタイプのAJAXリクエストを非ブロッキングと呼びます。これは、ユーザーに発生を認識せずに行われたAJAXリクエストであり、バックグラウンドで実行され、操作はサイレントです（AJAX呼び出しが正常に完了したことを示す詳細はありません）。目標は、操作が実際に終了していないときにすぐに発生したように見えるようにすることです。 ノンブロッキングAJAXリクエストの例を次に示します。 ユーザーがメールのコレクションで[削除]をクリックします。アイテムは受信トレイからすぐに消え、他の操作を続行できます。一方、AJAXリクエストはバックグラウンドでアイテムの削除を処理しています。 ユーザーが新しいレコードのフォームに入力します。保存をクリックします。新しいアイテムがリストにすぐに表示されます。ユーザーは引き続き新しいレコードを追加できます。 明確にするために、AJAX要求をブロックする例を次に示します。 ユーザーがメールのコレクションで[削除]をクリックします。砂時計カーソルが表示されます。AJAX要求が行われ、応答すると砂時計カーソルがオフになります。ユーザーは、操作が完了するまで1秒待つ必要があります。 ユーザーが新しいレコードのフォームに入力します。保存をクリックします。AJAXローダーをアニメーション化すると、フォームが灰色に変わります。「データが保存されました」というメッセージが表示され、新しいレコードがリストに表示されます。 上記の2つのシナリオの違いは、非ブロッキングAJAXセットアップでは動作のフィードバックが提供されないことと、ブロッキングAJAXセットアップでは提供されることです。 隠されたAJAXリクエストのリスク このスタイルのAJAX要求の最大のリスクは、AJAX要求が失敗したときにWebアプリケーションがまったく異なる状態になる可能性があることです。 たとえば、非ブロッキングの例。 ユーザーは多数のメールを選択します。削除ボタンをクリックします。操作はすぐに行われるように見えます（項目はリストから消えます）。次に、ユーザーは[作成]ボタンをクリックして、新しいメールの入力を開始します。この時点で、JavaScriptコードがAJAXリクエストが失敗したことを発見します。スクリプトはエラーメッセージを表示する可能性がありますが、現時点では本当に意味がありません。 または、ブロッキングの例。 ユーザーは多数のメールを選択します。削除ボタンをクリックします。砂時計が見えますが、操作は失敗します。「error。blah blah blah」というエラーメッセージが表示されます。それらは電子メールのリストに戻り、削除したい電子メールが選択されたままです。彼らは再びそれらを削除しようとする可能性があります。 ノンブロッキングAJAXリクエストを実行するための他の技術的リスクもあります。ユーザーはブラウザを閉じ、別のWebサイトに移動し、現在のWebの別の場所に移動して、エラー応答のコンテキストを無意味にすることができます。 それで、なぜそんなに人気が出るのでしょうか？ Facebook、Google、Microsoftなど。これらの大規模なドメインはすべて、非ブロッキングAJAXリクエストを使用して、操作が即座に実行されているように見せるようになっています。また、保存ボタンや送信ボタンのないフォームエディタが増えています。フィールドを出るかEnterキーを押すとすぐに。値が保存されます。プロフィールが更新されたというメッセージや保存手順はありません。 AJAXリクエストは確実ではなく、完了するまで成功として扱われるべきではありませんが、多くの主要なWebアプリケーションはそのように動作しています。 ノンブロッキングAJAX呼び出しを使用するこれらのWebサイトは、レスポンシブアプリケーションをシミュレートし、高速に表示されるという犠牲を払って不要なリスクを冒していますか？ これは、競争力を維持するために私たち全員が従うべき設計パターンですか？

48 design  web-development  javascript  ajax  error-handling 

私は職場で少し議論があり、誰が正しいのか、何が正しいのかを理解しようとしています。 コンテキスト：顧客が会計やその他のERPに使用するイントラネットWebアプリケーション。 （物事がクラッシュした場合）ユーザーに表示されるエラーメッセージには、スタックトレースなど、できるだけ多くの情報を含めるべきだと思います。もちろん、それはまず、「エラーが発生しました。開発者に以下の情報を送信してください」という大きなわかりやすい手紙で始める必要があります。 私の推論では、クラッシュしたアプリケーションのスクリーンショットがしばしば唯一の簡単に入手できる情報源になるということです。確かに、クライアントのシステム管理者の把握を試みたり、ログファイルの場所を説明したりすることができますが、それはおそらく遅くて苦痛です（ほとんどの場合、クライアントの担当者と話すのはそうです）。 また、すべての例外で必要なものを見つけるためにログファイルを探し回る必要のない開発では、即時かつ完全な情報を持つことが非常に役立ちます。（ただし、これは構成スイッチで解決できます。） 残念ながら、ある種の「セキュリティ監査」があり（ソースなしでどのように行われたかはわかりませんが...何でも）、彼らはセキュリティの脅威としてそれらを引用する完全な例外メッセージについて不平を言いました。当然、クライアント（私が知っている少なくとも1人）はこれを額面通りに受け取っており、現在はメッセージのクリーンアップを要求しています。 潜在的な攻撃者がスタックトレースを使用して、以前は理解できなかったものを把握する方法を理解できません。これまでにこれを行った人の例、証拠はありますか？私たちはこの愚かな考えと戦うべきだと思うが、おそらく私はここで愚か者だから... 誰が正しい？

45 security  error-handling 

ASP.NET MVC（この場合は3）でカスタムエラー処理を行うプロセスは、非常に軽視されているようです。ここで、ウェブ上で、さまざまなツール（エルマなど）のヘルプページのさまざまな質問と回答を読みましたが、完全な円になったのに、まだ最善の解決策がないと感じています。あなたの助けを借りて、おそらくエラー処理のための新しい標準的なアプローチを設定できます。私は物事をシンプルに保ち、これを過剰に設計したくないのです。 私の目標は次のとおりです。 サーバーエラー/例外の場合： devでデバッグ情報を表示する 本番環境でわかりやすいエラーページを表示する エラーを記録し、運用環境の管理者にメールで送信します 500 HTTPステータスコードを返す 404 Not Foundエラーの場合： わかりやすいエラーページを表示する エラーを記録し、運用環境の管理者にメールで送信します 404 HTTPステータスコードを返す ASP.NET MVCでこれらの目標を達成する方法はありますか？

44 asp.net  asp.net-mvc  error-handling  asp.net-mvc-3 

私は多くのSMBや企業に展開されるエンタープライズプロジェクトに取り組んでいます。 このプロジェクトのサポートは苦労するため、エラーのコーディングパターン（HTTPステータスコードなど）を作成したいと思います。これにより、ヘルプデスクの担当者がドキュメントを参照し、できるだけ早く問題をトラブルシューティングできます。 これを行うためのベストプラクティスと推奨事項は何ですか？ これを行うためのヘルプは役に立ちます。

43 c#  programming-practices  error-handling  enterprise-development