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

ネットワーク経由でMIDIを送信するための簡単な小さなプログラムを書いています。私は、プログラムが伝送の問題や予測できない他の例外状況に遭遇することを知っています。 例外処理については、2つのアプローチがあります。次のようにプログラムを作成する必要があります。 何かがうまくいかないときは強打で失敗する か、 データの整合性を犠牲にして、エラーを無視して続行する必要がありますか？ ユーザーはどのアプローチを合理的に期待しますか？ 例外を処理するより良い方法はありますか？ さらに、例外の処理に関する私の決定は、ネットワーク接続を処理しているかどうか（つまり、問題が発生することが合理的に予想できるもの）に影響されるべきですか？

20 exception-handling 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 例外をバグと呼ぶ場合、そもそも例外ではなく単にバグと呼ぶだけではどうでしょうか？ コード内で例外と呼ばれ、発生するとすぐにバグと呼ばれます。それでは、そもそもそれをバグと呼んでみませんか？ 回答やコメントをありがとうございます。

18 bug  debugging  issue-tracking  exceptions  exception-handling 

Javaプログラマーとして、私は未確認の例外に対して常に批判的でした。ほとんどのプログラマーは、後でトラブルを引き起こす場合にのみ、コーディングの容易さへの途中でそれを使用します。また、チェックされた例外を持つプログラム（乱雑ですが）は、チェックされていない対応するプログラムと比較して非常に堅牢です。 驚くべきことに、ScalaにはChecked Exceptionsと呼ばれるものはありません。Scalaでは、チェックされているJavaとチェックされていないJavaはすべてチェックされていません。 この決定の背後にある動機は何ですか？私にとっては、外部コードを使用するときにさまざまな問題が発生します。また、偶然ドキュメントの質が悪い場合は、KILLになります。

17 java  scala  exceptions  exception-handling 

投げることSystem.Exceptionがとても悪いと考えられるなら、そもそもなぜException行わabstractれなかったのですか？ そうすれば、以下を呼び出すことはできません。 throw new Exception("Error occurred."); これにより、派生した例外を使用して、発生したエラーに関する詳細を提供することができます。 たとえば、ライブラリのカスタム例外階層を提供する場合、通常、例外の抽象基本クラスを宣言します。 public abstract class CustomExceptionBase : Exception { /* some stuff here */ } そして、より具体的な目的を持ついくつかの派生した例外： public class DerivedCustomException : CustomExceptionBase { /* some more specific stuff here */ } 次に、ライブラリメソッドを呼び出すときに、この汎用try / catchブロックを使用して、ライブラリからのエラーを直接キャッチできます。 try { /* library calls here */ } catch (CustomExceptionBase ex) …

17 c#  exception-handling  abstract-class 

第二に、例外（例外制御フローの領域）と例外（Javaで使用されるものなど）の違いを誰かが知っているのか疑問に思っていました。 しかし、それらは基本的にユーザープログラムを終了することでシステムをクラッシュから保護するためにありますか？

16 exceptions  exception-handling 

デフォルトのコンストラクターについて具体的に尋ねる コンストラクターがオブジェクトのすべてのデータを初期化する場合、適切な初期化なしでは使用できないクラスを作成すると、デフォルトのコンストラクターが役に立たなくなるわけではありませんか？考慮してください： // A class for handling lines in a CSV file class CSV_Entry { private: unsigned num_entries; std::string string_version; std::vector<std::string> vector_version; ...etc public: CSV_Entry(); CSV_Entry(const std::string& src_line); // returns a vector copy of the original entry std::vector<std::string> get_vector_snapshot(); } int main( void ) { ...etc CSV_Entry example = CSV_Entry(); …

14 exceptions  exception-handling  initialization  constructors 

オブジェクトを取得しようとしている状況があります。ルックアップが失敗した場合、フォールバックがいくつかあり、それぞれが失敗する可能性があります。したがって、コードは次のようになります。 try { return repository.getElement(x); } catch (NotFoundException e) { try { return repository.getSimilarElement(x); } catch (NotFoundException e1) { try { return repository.getParentElement(x); } catch (NotFoundException e2) { //can't recover throw new IllegalArgumentException(e); } } } これはひどくいです。nullを返すのは嫌いですが、このような状況ではより良いですか？ Element e = return repository.getElement(x); if (e == null) { e = repository.getSimilarElement(x); …

14 java  exception-handling 

処理できる例外のみをキャッチする必要があることを読みました。これにより、ベース例外クラス（この場合はC＃）をキャッチするのは悪い考えです（他の理由に加えて）。現在、私はプロジェクトの一部であり、これまでのところ、キャッチされている基本例外以外は何も見ていません。そうするのは悪い習慣と見なされると述べましたが、応答は「このサービスは24時間365日実行する必要があるため、そうです」でした。 24時間年中無休で実行する必要のあるプログラムで例外を適切に処理する方法についての良い応答がなかったため、ここにいます。24時間実行する必要のある「重要な」プログラム/サービスの例外処理に対処する方法に関する情報/提案を見つけることができませんでした（この場合、サービスが1分間停止しても大丈夫かもしれません）または2つなので、重要ではありません）。私はそれがプログラムの正確な性質に依存することを理解しています。命にかかわる問題を引き起こす可能性のあるプログラムの要件は、オンラインゲームのログスキャナーとはまったく異なります。 2つの例： 1：イギリス鉄道の顧客向けの先行入力サービス。鉄道駅をオンラインで検索するときに使用されます。 2：線路、列車などのさまざまなセンサーから提供されるリアルタイム情報に基づいて、上記の鉄道の鉄道スイッチを自動的に制御するプログラム。 最初のプログラムが1、2分間停止しても、おそらく大きな問題は発生しませんが、後者は人的被害を引き起こす可能性があります。それぞれに対処する方法の提案？この問題に関する詳細情報と考えを見つけることができる場所へのポインター？

14 exception-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 

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

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

コードの別の部分が正しくコーディングされていない場合に備えて、無駄な例外処理を実装することをお勧めしますか？ 基本的な例 単純なものなので、私は皆を失うわけではありません:)。 データベースから抽出されたデータを人の情報（名前、住所など）を表示するアプリを書いているとしましょう。私がUI部分をコーディングしている人で、他の誰かがDBクエリコードを書いているとしましょう。 ここで、アプリの仕様で、人の情報が不完全な場合（データベースに名前がないなど）、クエリをコーディングしている人が、不足しているフィールドに「NA」を返すことでこれを処理する必要があると考えているとします。 クエリのコーディングが不十分で、このケースを処理できない場合はどうなりますか？クエリを作成した人が不完全な結果を処理し、情報を表示しようとすると、コードが空のものを表示する準備ができていないため、すべてがクラッシュするとどうなりますか？ この例は非常に基本的なものです。私はあなたのほとんどが「あなたの問題ではない、あなたはこのクラッシュの責任を負わない」と言うと信じています。ただし、クラッシュするのは依然としてコードの一部です。 もう一つの例 今、私がクエリを書いている人だとしましょう。仕様は上記と同じではありませんが、「挿入」クエリを作成する人は、データベースに人を追加するときにすべてのフィールドが完全であることを確認して、不完全な情報を挿入しないようにする必要があります。UIの人に完全な情報を提供するために、「選択」クエリを保護する必要がありますか？ 質問 仕様に「この人がこの状況を処理する責任者である」と明示的に述べていない場合はどうなりますか？第三者が別のクエリ（最初のクエリに似ていますが、別のDB上にある）を実装し、UIコードを使用してそれを表示しますが、コードでこのケースを処理しない場合はどうなりますか？ 私が悪いケースを処理することになっていない場合でも、起こりうるクラッシュを防ぐために必要なことをすべきですか？ 私はここで衝突を解決していないので、「（彼）がクラッシュの原因である」などの答えを探していません。私の責任ではない状況からコードを保護する必要があります処理する？ここでは、単純な「空の場合は何かを行う」で十分です。 一般に、この質問は冗長な例外処理に取り組んでいます。私がそれを求めているのは、私がプロジェクトで一人で作業するとき、「万が一に備えて」何か間違ったことをして、悪いケースを通過させるために、連続する関数で同様の例外処理を2〜3回コーディングする可能性があるためです。

12 language-agnostic  validation  exception-handling 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 5年前に閉鎖されました。 私のプログラムの主な問題は、コード構造/組織とエラー処理の2つだと思います。Code Complete 2を読んでいますが、潜在的な問題を扱うために読むものが必要です。 たとえば、Webサイトで、ユーザーがjavascriptを介してデータを改ざんした場合にのみ何かが発生する可能性がある場合、そのことについて記述しますか？また、いつエラーをキャッチしませんか？入力として文字列とintを期待するクラスを作成し、それらが文字列とintではない場合、それを確認しますか、それとも間違ったパラメーターを渡した呼び出しメソッドにバブルさせますか？ これはここでの単一の回答では答えられない広範なトピックであることを知っているので、私が探しているのは、適切な例外処理の実践を教えるとして一般に受け入れられている本またはリソースです。

12 programming-practices  books  exceptions  exception-handling 

これは関連しているQ： 返品後の作業を行うためのfinally節の使用は、スタイルが悪い/危険ですか？ 参照されるQでは、最終的に使用されるコードは、使用される構造とプリフェッチの必要性に関連しています。私の質問は少し異なりますが、より多くの聴衆にとって密接な関係があると思います。私の特定の例はC＃winformアプリですが、これは最終的にC ++ / Javaの使用にも適用されます。 私は、ブロックに例外や例外処理/クリーンアップに関係のないコードがたくさんあるtry-catch-finallyブロックにかなり気付いています。そして、例外と処理に密接に関連するコードで非常にタイトなtry-catch-finallyブロックを作成するという私のバイアスを認めます。ここに私が見ているもののいくつかの例があります。 tryブロックには、スローされる可能性のあるコードに至るまでの多くの予備的な呼び出しと変数が設定されます。ロギング情報は、セットアップを取得し、tryブロックでも実行されます。 最後に、ブロックはform / module / controlのフォーマット呼び出し（catchブロックで表されるように、アプリが終了しようとしているにもかかわらず）を持ち、パネルなどの新しいオブジェクトを作成します。 大体： methodName（...） { 試してみる { //メソッドの多くのコード... //スローできるコード... //メソッドとリターンのためのより多くのコードを... } catch（何か） {//例外を処理する} 最後に { //例外によるいくつかのクリーンアップ、クローズ //作成されたもののためのより多くのコード（例外がスローされる可能性があることを無視）... //さらにオブジェクトを作成します } } コードは機能するため、何らかの価値があります。それはうまくカプセル化されておらず、ロジックは少し複雑です。私は（苦労して）コードを移動したりリファクタリングしたりするリスクに精通しているので、私の質問は、同様に構造化されたコードに関する他の人の経験を知りたいということになります。 悪いスタイルは変更を加えることを正当化しますか？同様の状況で誰かがひどくやけどをしたことがありますか？その悪い経験の詳細を共有してくれませんか？私が過剰に反応していて、スタイルがそれほど悪くないので、それを残してください？物事を片付けることのメンテナンスの利点を得る？

11 design  exception-handling  coding-style 

公開SDKでは、例外が発生する理由について非常に有益なメッセージを提供する傾向があります。例えば： if (interfaceInstance == null) { string errMsg = string.Format( "Construction of Action Argument: {0}, via the empty constructor worked, but type: {1} could not be cast to type {2}.", ParameterInfo.Name, ParameterInfo.ParameterType, typeof(IParameter) ); throw new InvalidOperationException(errMsg); } ただし、コードが何をしているのかではなく、エラーメッセージに重点を置く傾向があるため、コードの流れが煩雑になる傾向があります。 同僚は、次のようなものにスローする例外の一部をリファクタリングし始めました： if (interfaceInstance == null) throw EmptyConstructor(); ... private Exception EmptyConstructor() …

11 c#  .net  clean-code  exception-handling 

if...else例外処理でラップされた通常の場合、次の例のようなものはコードの重複を避けるための推奨される方法ですか？ try { if (GetDataFromServer()) { return ProcessData(); } else { throw new Exception(); } catch(Exception ex) { return null; } の代わりに... try { if (GetDataFromServer()) { return ProcessData(); } else { return null; } } catch(Exception ex) { return null; } パフォーマンスにわずかな影響があることは知っていますが、これが許容できるプラクティスであると考えられるかどうか疑問に思っています。私は現在、2番目の方法（特に、特定の例外を異なる方法で処理する必要がある場合）を実行していますが、最初の方法が単純なケースに適しているかどうか疑問に思っていました。

10 c#  exception-handling