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

ここで私が確信していないコードについて質問したところ、誰かが「ところで、恐ろしいコード：エラー抑制記号（@）を多く使用しています」と答えました。 これが悪い習慣である理由はありますか？のようなもので： $db=@new mysqli($db_info) or die('Database error'); 、カスタムエラーメッセージのみを表示できます。エラーを抑制しないと、次の典型的なPHPメッセージが表示されます。 警告：mysqli :: mysqli（）：php_network_getaddresses：getaddrinfo failed：そのようなホストは不明です。中にいくつかの\ファイル\パス上のライン6 「データベースエラー」も同様です。 エラー抑制は常に悪いですか、もしそうなら、上記について具体的に何が悪いですか？ 更新：私が使用している実際のコードは次のとおりです。 or error('Datatabase error', 'An error occurred with the database' . (($debug_mode) ? '<br />MySQL reported: <b>' . $db->error . '</b><br />Error occurred on line <b>' . __LINE__ . '</b> of <b>' . __FILE__ . '</b>' …

14 php  programming-practices  error-handling 

システムエラー、例外処理（Java、C ++、Perl、PHP）を公開/許容/回復するための設計パターン/アプローチを推奨できますか？ いくつかのエラーを報告する必要があります。 一部のエラーは、内部的に処理することができます（再試行によるか、重要ではありません（無視できます）。 それらをキャッチするコードをどのように構成しますか？ ただし、すべてのエラーを記録する必要があります。 どんなベストプラクティスがありますか？ そして、それらの影響を受けるコンポーネントを完全にテストできるようにそれらをシミュレートするには？ いくつかの現代のプログラミング言語に適用可能な一般的な非プログラミング言語固有の質問ですが、Java、C ++、PHP、およびPerlのパターン、アプローチ、哲学の例図を歓迎します。 （stackoverflowでも尋ねました：https ://stackoverflow.com/questions/7432596/recommend-a-design-pattern-approach-to-exposing-tolerating-recovering-from-systemです が、プログラマーにも尋ねるべきだと思いましたプログラマーのQ＆Aは、より広範なソフトウェア/プログラミングの問題をカバーしているのに対し、stackoverflowは技術的な実装に関するものです（IMHO）。

13 design-patterns  philosophy  error-handling  exception-handling 

私はtrigger_error、魔法のメソッドのコンテキストでの正しい使用法（もしあれば）について同僚と議論しています。まず、この1つの場合を除いて、それtrigger_errorは避けるべきだと思います。 1つのメソッドを持つクラスがあるとします foo() class A { public function foo() { echo 'bar'; } } まったく同じインターフェースを提供したいが、すべてのメソッド呼び出しをキャッチするためにマジックメソッドを使用するとします class B { public function __call($method, $args) { switch (strtolower($method)) { case 'foo': echo 'bar'; break; } } } $a = new A; $b = new B; $a->foo(); //bar $b->foo(); //bar 両方のクラスの応答方法は同じですfoo()が、無効なメソッドを呼び出す場合は異なります。 $a->doesntexist(); //Error $b->doesntexist(); …

13 php  error-handling 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 私は数年間プロレベルでプログラミングを行ってきましたが、それでもエラー処理を完全に理解していません。私のアプリケーションは正常に動作しますが、エラー処理は専門的なレベルでは実装されておらず、多くの手法の組み合わせです。 エラー処理の背後に構造はありません。プロレベルでどのように実装されているかを学び、理解したいと思います。これは、私が知識を欠いている分野の1つです。 ロジックフローでチェックするために、いつ例外を使用し、成功ステータスを返す必要がありますか？例外を組み合わせてステータスを返すことはできますか？ 主にC＃でコーディングします。

13 c#  .net  coding-standards  error-handling 

次のように表すことができるコードがあります： public class ItemService { public void DeleteItems(IEnumerable<Item> items) { // Save us from possible NullReferenceException below. if(items == null) return; foreach(var item in items) { // For the purpose of this example, lets say I have to iterate over them. // Go to database and delete them. } } …

12 c#  exceptions  error-handling 

当社のアプリケーションのいくつかでは、カスタムロガーを使用しています。かなり堅牢ですが、将来NLogのようなものに置き換える可能性があります。ロガーのタスクの1つは、アプリケーションで発生した例外をログに記録することです。 私が常に抱えていた懸念の1つは、ロガー内の例外処理がサイレント障害を許容することです。つまり、ログが特定の例外（ロガーのエラーのため）に書き込まれていない場合、どのようにログを処理し、（どういうわけか）ロガー自体に例外を記録する必要がありますか？ WriteLog関数が例外をスローするとします。関数を何回か、または例外がスローされなくなるまで呼び出そうとしますか？スローされた例外をロガーで書き込もうとする必要があります（これにより、例外が発生する可能性が高くなります。最初にカスタムロガーを実装していたときを除いて、この状況に出会えないほど幸運でした。一方で、ロガーがアプリケーションの例外（独自の例外のため）のログに失敗したかどうかを現時点で知る方法はありません。 私はオンラインといくつかのSEサイトで検索しようとしましたが、すべての投稿がロガーのエラー（潜在的な例外とそれらのログ方法ではありません）またはロガー外の例外を扱っているため、これまでのところ無駄です。

12 design-patterns  exceptions  exception-handling  logging  error-handling 

テキストファイルに対して何かを行うスクリプトを書いています（ただし、それは私の質問とは無関係です）。そのため、ファイルに何かを行う前に、ファイルが存在するかどうかを確認します。私はこれを行うことができますが、問題はありませんが、問題は美学の問題です。 これは、同じことを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 

システム/プログラム/分散アルゴリズム/ ...は、多くの場合、述語堅牢またはフォールトトレラントで記述されています。 違いはなんですか？ 詳細： + robust + "fault-tolerant"でGoogleを検索すると、2回しかヒットしませんが、どちらも役に立ちません。 Googleで学者の用語を検索すると、タイトルに両方の用語が含まれている多くの論文が見つかります。残念ながら、彼らは用語を正確に定義していません:(しかし、彼らは両方の用語を使用しているので、どちらも他方を意味しないようです。

12 architecture  error-handling  errors  definition  failure 

私たち（およびJS SOチャットルーム）は、エラー処理に関する彼のLittle-XHRライブラリについて、数日前に@rlemonと話しました。 基本的に、どのエラー処理パターンを使用するかを決定したかったのです。 xhr.get({ // Some parameters, and then success: function(data) {}, failure: function(data) {} }) または： xhr.get({ // Some parameters, and then callback: function(err, data) {} }) 1つはjQueryに似ていますが、もう1つはノードに似ています。最初のパターンは、エラーの処理についてもっと考えるようになると言う人もいます。あなたは他のコールバック関数を忘れるかもしれないので、私は反対だと思いますが、引数は常に2番目のパターンにあります。 これらの両方のパターンに関する意見/利点/欠点はありますか？

12 javascript  error-handling 

私は最近Codeigniterを頻繁に使用していますが、気になるのはエラーを処理してユーザーに表示することです。乱雑になることなくエラーを処理するのが得意ではありませんでした。私の主な関心事は、ユーザーにエラーを返すときです。 関数から0または1を返し、if / elseを使用してエラーを処理するのではなく、例外と例外をスロー/キャッチすることをお勧めします。したがって、問題についてユーザーに簡単に通知できます。 私は例外から離れる傾向があります。数年前、大学の私のJava講師は「例外はプロダクションコードで使用すべきではありません。デバッグ用ではありません」と言っていました。私は彼が嘘をついていると感じました。 しかし、例として、ユーザーをデータベースに追加するコードがあります。プロセス中に、データベースの問題、重複エントリ、サーバーの問題など、2つ以上の問題が発生する可能性があります。登録中に問題が発生した場合、ユーザーはそれについて知る必要があります。 MVCフレームワークを使用していることを念頭に置いて、PHPでエラーを処理する最良の方法は何ですか。

12 php  mvc  error-handling 

（主に）ネイティブクライアント（Windows、C ++）と通信するWebサービス（SOAP、.Net）を構築しており、クライアントにエラーを伝える最良の方法は何かを考えています（例：ログインサービスが利用できないSomethingBadHappenedまたはユーザーが見つからないなど）、クライアントに例外をスローするか、上記を行うために何らかのエラーコードモデルを使用するかを決定できませんでした。 クライアント側の処理であなたが好むもの：エラーコードを受け取るか、エラーの理由を含むServerFault例外を処理しますか？ 1）なぜ例外を考えているのか：サーバー側のコードをより均一にするから 2）エラーコードを考えているのはなぜか：クライアント側の観点からより理にかなっていると考えるから 2）が本当に当てはまる場合、例外よりもエラーコードを探したいのでしょうか？それはここですか？ また、ネイティブクライアントではなくマネージドクライアントと通信している場合、答えは変わりますか？

12 programming-practices  exceptions  error-handling 

外部の開発者が使用している商用ライブラリとコード例を作成します。ライブラリの使用方法を広範囲に説明する（登録済みユーザーは利用できますが、閉鎖された）ドキュメントがあります。 開発者の多くは初めてのユーザーなので、多くの初歩的なエラーが発生します。 エラーログにドキュメントへのリンクを含めることは適切ですか？考えられる欠点は何ですか？いくつかは予想できますが、以下を克服することは可能と思われます ドキュメントの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 

データベースでデータの変更（挿入、更新、削除）を実行するいくつかのメソッドがあります。ORMは、私は方法のこれらのタイプの戻り行の影響を受けたint型の値を使用しています。操作の成功/失敗の状態を示すために、「私のメソッド」に対して何を返す必要がありますか？ を返すコードを考えてみましょうint： A.1 public int myLowerLevelMethod(int id) { ... int affectedRows = myOrm.deleteById(id) ... return affectedRows; } 次に、使用法： A.2 public void myOtherMethod() { ... int affectedRows = myLowerLevelMethod(id) if(affectedRows > 0) { // Success } else { // Fail } } ブール値を使用する場合と比較してください。 B.1 public boolean myLowerLevelMethod(int id) { ... int …

10 design  error-handling  methods 

システムが例外を適切に伝達および処理するために必要な多くの要件があります。概念を実装するために言語を選択するための多くのオプションもあります。 例外の要件（順不同）： ドキュメント：言語には、APIがスローできる例外をドキュメント化する手段が必要です。理想的には、このドキュメントメディアは、コンパイラとIDEがプログラマにサポートを提供できるようにマシンで使用できる必要があります。 例外的な状況の送信：これは明らかです。呼び出された機能が期待されるアクションを実行できない状況を関数が伝達できるようにするためです。私の意見では、そのような状況には3つの大きなカテゴリがあります。 2.1一部のデータが無効になる原因となるコードのバグ。 2.2構成またはその他の外部リソースの問題。 2.3本質的に信頼できないリソース（ネットワーク、ファイルシステム、データベース、エンドユーザーなど）。これらは信頼できない性質のため、散発的な障害が発生する可能性があるため、ちょっとしたケースです。この場合、これらの状況は例外的と見なされますか？ コードがそれを処理するための十分な情報を提供する：例外は、呼び出し先に対応し、状況を処理できるように、十分な情報を呼び出し先に提供する必要があります。ログに記録されたときに、この例外がプログラマーに問題のあるステートメントを識別して分離し、解決策を提供するのに十分なコンテキストを提供できるように、情報も十分でなければなりません。 プログラマーにコードの実行状態の現在のステータスについて自信を与える：ソフトウェアシステムの例外処理機能は、プログラマーの邪魔にならないようにしながら必要な安全策を提供するために十分に存在している必要があります。手。 これらをカバーするために、以下のメソッドがさまざまな言語で実装されました。 チェックされた例外は例外 を文書化する優れた方法を提供し、理論的には正しく実装された場合、すべてが良好であることを十分に保証するはずです。ただし、コストがかかるため、多くの場合、例外を飲み込むか、チェックされていない例外として再スローすることで単にバイパスする方が生産性が高くなります。不適切にチェックされた例外を使用すると、ほとんどすべての有用性が失われます。また、チェックされた例外は、時間的に安定したAPIの作成を困難にします。特定のドメイン内で汎用システムを実装すると、チェックされた例外のみを使用して維持することが困難になる例外的な状況が大量に発生します。 チェックされていない例外 - チェックされた例外よりもはるかに用途が広く、特定の実装で起こり得る例外的な状況を適切に文書化できません。彼らは、仮にあったとしてもその場限りの文書に依存しています。これにより、メディアの信頼できない性質が、信頼性のある外観を提供するAPIによってマスクされます。また、これらの例外がスローされると、抽象化レイヤーを逆方向に移動するときに意味が失われます。それらは十分に文書化されていないため、プログラマーはそれらを明確に対象とすることができず、セカンダリシステムで障害が発生した場合にシステム全体を停止させないために、必要以上に広いネットをキャストする必要があります。これにより、提供された嚥下問題チェック例外に戻ることができます。 マルチステートの戻り値の型 ここでは、予想外の結果または例外を表すオブジェクトを返すために、ばらばらのセット、タプル、またはその他の同様の概念に依存しています。ここでは、スタックの巻き戻し、コードのカットは行われません。すべてが正常に実行されますが、続行する前に戻り値のエラーを検証する必要があります。私はまだこれを実際に使用していませんので、経験からコメントすることはできません。通常のフローをバイパスしていくつかの問題の例外を解決しますが、チェックされた例外とほとんど同じ問題があり、面倒で常に「直面しています」。 だから問題は： この問題についてのあなたの経験は何ですか、そしてあなたによると、言語が持つ優れた例外処理システムを作るための最良の候補は何ですか？ 編集：この質問を書いてから数分後、私はこの投稿に出くわしました、不気味です！

10 exceptions  error-handling 

パブリックメソッドの引数を検証することをお勧めします。 彼がnullを期待していない場合、nullをチェックする必要がありますか？ メソッドはパラメータを検証する必要がありますか？ MSDN-CA1062：パブリックメソッドの引数を検証します（.NETの背景がありますが、質問はC＃固有ではありません） 動機は理解できます。モジュールが誤った方法で使用される場合は、予測できない動作ではなく、すぐに例外をスローする必要があります。 気になるのは、モジュールの使用中に発生する可能性のあるエラーは間違った引数だけではないということです。推奨事項に従ってエラーのエスカレーションを望まない場合に、チェックロジックを追加する必要があるいくつかのエラーシナリオを以下に示します。 着信-予期しない引数 着信-モジュールの状態が間違っています 外部呼び出し-予期しない結果が返されました 外部呼び出し-予期しない副作用（呼び出しモジュールへの二重入力、他の依存関係の状態を壊す） 私はこれらすべての条件を考慮して、1つのメソッド（申し訳ありませんが、C＃ではありません）で単純なモジュールを作成しようとしました： public sealed class Room { private readonly IDoorFactory _doorFactory; private bool _entered; private IDoor _door; public Room(IDoorFactory doorFactory) { if (doorFactory == null) throw new ArgumentNullException("doorFactory"); _doorFactory = doorFactory; } public void Open() { if (_door != null) throw …

9 design  code-quality  coding-standards  exceptions  error-handling