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

小さなライブラリをコーディングしていますが、例外処理の設計に問題があります。私はC ++言語のこの機能に（まだ）混乱していると言わざるを得ません。例外クラスを適切に処理するために何をしなければならないかを理解するために、この件について可能な限り読んでみました。 クラスのsystem_errorSTL実装からインスピレーションを得たタイプのアプローチを使用することにしましたfuture_error。 エラーコードを含む列挙があります： enum class my_errc : int { error_x = 100, error_z = 101, error_y = 102 }; そして、単一の例外クラス（error_category構造のタイプとsystem_errorモデルが必要とする他のすべてによってバックアップされます）： // error category implementation class my_error_category_impl : public std::error_category { const char* name () const noexcept override { return "my_lib"; } std::string message (int ec) const override { std::string …

9 c++  error-handling  libraries 

私はこの質問について、例外が発生した場所にできるだけ近いところで例外を処理する方法についてのアドバイスを読んでいます。 ベストプラクティスのジレンマは、try / catch / finallyを使用してenum （または値を表すint、エラーの場合は0、OKの場合は1、警告の場合は2など）を返す必要があるかどうかです。答えは常に正しいですか、それとも呼び出し側がそれを処理するように例外を通過させるべきですか？ 私が集めることができるものから、場合によってはこれが異なるかもしれないので、元のアドバイスは奇妙に思えます。 たとえば、Webサービスでは、常に状態を返す必要があるため、例外はその場で処理する必要がありますが、http経由でデータを投稿/取得する関数内で、例外（たとえば404の場合）は、それを起動したものにパススルーするだけです。そうでない場合は、結果の品質（エラー：404）と結果自体を呼び出し側に通知する方法を作成する必要があります。 データを取得/ポストするヘルパー関数内で404例外をキャッチすることは可能ですが、そうする必要がありますか？smallintを使用してプログラムの状態を示し（もちろん、それらを適切に文書化し）、この情報を外部の健全性検証の目的（すべてok /エラー処理）に使用するのは私だけですか？ 更新：メインの分類で致命的または致命的でない例外を予期していましたが、回答を害しないようにこれを含めたくありませんでした。質問が何であるかを明確にしましょう：例外をスローするのではなく、スローされる例外を処理します。望ましい結果とは：エラーを検出し、エラーからの回復を試みます。復旧できない場合は、最も意味のあるフィードバックを提供してください。 ここでも、http get / postの例での問題は、元の呼び出し元に何が起こったかを説明する新しいオブジェクトを提供する必要があるかということです。このヘルパーが使用しているライブラリにあった場合、操作のステータスコードを提供することを期待しますか、それともtry-catchブロックに含めますか？設計している場合、ステータスコードを提供するか、例外をスローして、代わりに上位レベルにステータスコード/メッセージに変換させますか？ あらすじ：例外を生成するのではなく、コードの一部がステータスコードと、コードが生成する結果を返す場合、どのように選択しましたか？

9 exceptions  error-handling  exception-handling 

当社は、数千のサービスを含むマイクロサービスアーキテクチャでアプリケーションを実行しています。50以上のサービスと通信するバックエンドアプリケーション「X」に取り組んでいます。フロントエンドサービスは他のサービスでリクエストを実行するためにサービス「X」を呼び出します。 問題点： フロントエンドは、他のサービスで何かが失敗したときに、ユーザーフレンドリーなメッセージを表示したいと考えています。 他のサービスはユーザーフレンドリーなメッセージを返しません。いくつかあるため、他のチームに変更を依頼することはできません。 そのような合意されたエラーコードはありません。他のサービスは文字列エラーメッセージを返します。現在、UIに渡されます。時々、エラーメッセージはポインタ参照です（悪いコード：/） 可能な解決策： エラーメッセージ文字列を確認し、サービスにユーザーフレンドリーなメッセージへのマッピングを含めます。ただし、呼び出し先のサービスがエラーメッセージを変更した場合は、問題が発生する可能性があります。カスタムエラーマッピングが見つからない場合のデフォルトのエラーメッセージへのフォールバック。 スケーラブルで持続可能なソリューションに関する他のアイデアはありますか？ありがとう！

8 api  microservices  error-handling 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 3年前休業。 毎日何百ものCURL要求、SMTP要求、およびその他の要求を行うプログラムがあります。1％未満の時間で、CURLまたはSMTP要求は失敗します。問題の原因は外部にあり、100％信頼できるように修正することはできません。私のプログラムはいつでもそれから回復することができ、そこから人間の相互作用は必要ありません。何かが失敗したときに電子メールアラートを送信するシステムを導入しています。私が受け取るものの大部分は、これらの無害なCURLおよびSMTPの失敗です。 プログラムが回復する一般的な障害について、電子メールアラートを送信しないでください。

8 design  error-handling 

スローデストラクタを備えた型と、それを値で受け取る関数があるとします。 その操作は、基本的な例外保証よりも優れたものを提供できますか？ または別の方法で定式化すると、操作にコミットアンドロールバックセマンティクスがあるかどうかを判断するときに、値によって渡された引数の破棄を無視できますか？ #include <cstdlib> struct X { ~X() noexcept(0) { if(rand()%6 == 0) throw 0; } // some state }; void update(database db, X arg) noexcept; X x; update(db, x); 個人的には、ウィキペディアの定義に基づく 強力な例外安全性、コミットまたはロールバックセマンティクスとも呼ばれます：操作は失敗する可能性がありますが、失敗した操作には副作用がないことが保証されているため、すべてのデータは元の値を保持します 関数自体がスローすることさえできないとしてもupdate、強く例外セーフであると説明することは有用ではないと私は思います。 私は私の現在の理解の愚かさを私に示してくれる人、あるいはもっと良い議論をしてくれれば幸いです。

8 c++  exceptions  exception-handling  error-handling 

質問：一般向けのWeb API（HTTP Get / Postリクエストを送信し、JSON / XMLデータを取得する）の場合、スペルが間違っているか余分なパラメーターをどのように処理する必要がありますか？ 正しくないパラメーターが無視された場合、呼び出し元のコードのエラーは、有効な結果を返すため、気付かれないように思えます。これは、返された結果を見ても明らかではない状況で特に当てはまる可能性があります。 オプションのパラメーターのみを参照しています。明らかに、必須パラメーターのスペルが間違っている場合、パラメーターは欠落していると見なされ、エラーが返されます。 例として、Place Search API呼び出しには4つの必須パラメーター（位置、半径、センサー、キー）といくつかのオプションパラメーター（タイプはそのうちの1つ）があります。 これらのコマンドを（APIキーを使用して）実行し、有効な結果を取得できます。 curl "https://maps.googleapis.com/maps/api/place/search/json?location=45.47554,-122.794189&radius=500&sensor=false&key=<api_key>&type=bakery" curl "https://maps.googleapis.com/maps/api/place/search/json?location=45.47554,-122.794189&radius=500&sensor=false&key=<api_key>&types=bakery" 最初のコマンドには、「types」パラメーターが単数形であり、これは無効なキー名です。APIはそのパラメーターを無視し、すべてのタイプのエンティティを返します。この場合、エラーは明白ですが、発生しない場合（および他のAPI呼び出し）がある場合があります。

8 api  error-handling 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 「404ページが見つかりません」のようなエラーページにどのようなコンテンツを入れればよいですか？ 例： 「申し訳ありませんが、ページリクエストの処理中にエラーが発生しました。」 「ページが見つかりません！URLを確認してください」 「エラーが発生しました。もう一度やり直してください。」 「申し訳ありませんが、リクエストされたページが見つかりませんでした。」 コンテンツは、ターゲットユーザーの視点である必要があります。対象ユーザーが何が起こっているのか、何をすべきかを簡単に理解できるはずですか？

8 user-interface  error-handling