タグ付けされた質問 「exceptions」

C ++での例外処理は、try / throw / catchに制限されています。Object Pascal、Java、C＃、Pythonとは異なり、C ++ 11でもfinallyコンストラクトは実装されていません。 「例外の安全なコード」について議論しているC ++の文献がたくさんあります。リップマンは、例外セーフコードは重要だが高度で難しいトピックであり、彼の入門書の範囲を超えていると書いています。これは、セーフコードがC ++の基本ではないことを暗示しているようです。ハーブサッターは、例外的なC ++のトピックに10章を費やしています！ しかし、「例外セーフコード」を記述しようとするときに遭遇する問題の多くは、finally構造が実装されていれば非常によく解決でき、プログラマは例外が発生した場合でもプログラムを復元できるようになりますリソース、潜在的に問題のあるコードの割り当てのポイントに近い、安全で安定した、漏れのない状態に。私は非常に経験豊富なDelphiおよびC＃プログラマーとしてtry ..を使用します。これらの言語のほとんどのプログラマーと同様に、最終的にコード内でかなり広範囲にブロックします。 C ++ 11に実装されているすべての「付加機能」を考慮すると、「最終的に」まだ存在していないことに驚いた。 それでは、なぜfinallyコンストラクトがC ++で実装されていないのでしょうか？把握するのはそれほど難しくも高度な概念でもないので、プログラマーが「例外安全なコード」を書くのを支援するのに大いに役立ちます。

57 c++  exceptions 

私は通常、ほとんどのコード分析の警告に同意し、それらを順守しようとします。しかし、私はこれで苦労しています： CA1031：一般的な例外タイプをキャッチしない このルールの根拠を理解しています。しかし、実際には、スローされた例外に関係なく同じアクションを実行したい場合、それぞれを具体的に処理するのはなぜですか？さらに、特定の例外を処理する場合、呼び出しているコードが変更されて将来新しい例外がスローされるとどうなりますか？次に、その新しい例外を処理するためにコードを変更する必要があります。一方、単にExceptionコードをキャッチしただけなら、変更する必要はありません。 たとえば、FooがBarを呼び出し、FooがBarによってスローされた例外のタイプに関係なく処理を停止する必要がある場合、キャッチしている例外のタイプを特定することに利点はありますか？ たぶんより良い例： public void Foo() { // Some logic here. LogUtility.Log("some message"); } public static void Log() { try { // Actual logging here. } catch (Exception ex) { // Eat it. Logging failures shouldn't stop us from processing. } } ここで一般的な例外をキャッチしない場合は、可能なあらゆる種類の例外をキャッチする必要があります。パトリックには、OutOfMemoryExceptionこの方法で対処すべきでない良い点があります。では、例外をすべて無視したい場合はどうしOutOfMemoryExceptionますか？

57 c#  design  exceptions 

このスタイルに賛否両論があるかどうか疑問に思っています。 private void LoadMaterial(string name) { if (_Materials.ContainsKey(name)) { throw new ArgumentException("The material named " + name + " has already been loaded."); } _Materials.Add( name, Resources.Load(string.Format("Materials/{0}", name)) as Material ); } そのメソッドは、それぞれnameに対して1回だけ実行する必要があります。_Materials.Add()同じに対して複数回呼び出されると、例外がスローされますname。その結果、私のガードは完全に冗長なのでしょうか、それともそれほど明白でない利点がありますか？ 誰かが興味を持っているなら、それはC＃、Unityです。

52 exceptions 

約10年以上前の学校に戻って、彼らは例外指定子の使用を教えていました。私のバックグラウンドは彼らの1人であるため、強制されない限り頑固にC ++を避けるトーバルディッシュCプログラマーなので、私は散発的にC ++になってしまい、私が教えられたので例外指定子を使用しています。 ただし、C ++プログラマの大半は、例外指定子に眉をひそめているようです。これらのようなさまざまなC ++の達人からの議論と議論を読みました。私の知る限り、それは次の3つに要約されます。 例外指定子は、残りの言語と矛盾する型システムを使用します（「シャドウ型システム」）。 例外指定子を持つ関数が、指定したもの以外の何かをスローする場合、プログラムは悪い、予期しない方法で終了します。 例外指定子は、今後のC ++標準で削除される予定です。 ここで何かが足りないのですか、それともすべての理由ですか？ 私自身の意見： 1）に関して：それで何。C ++はおそらく、構文的にはこれまでに作成された中で最も一貫性のないプログラミング言語です。マクロ、goto / labels、undefined- / unspecified- / implementation-defined動作の大群（hoard？）、不十分に定義された整数型、すべての暗黙的な型昇格規則、friend、autoなどの特別な場合のキーワードがあります。 、登録、明示...など。おそらく、C / C ++のすべての奇妙さについての厚手の本をいくつか書くことができます。それでは、なぜ人々はこの特定の矛盾に反応するのでしょうか。これは、言語の他の多くのより危険な機能と比較して、小さな欠陥です。 2）に関して：それは私自身の責任ではありませんか？C ++で致命的なバグを作成できる方法は他にもたくさんありますが、なぜこの特定のケースはさらに悪いのでしょうか？throw(int)Crash_t を記述してからスローする代わりに、関数がintへのポインターを返し、ワイルドで明示的な型キャストを行い、Crash_tへのポインターを返すと主張することもできます。C / C ++の精神は、ほとんどの責任をプログラマに任せることでした。 では、利点はどうですか？最も明白なのは、関数が指定したもの以外の型を明示的にスローしようとすると、コンパイラーがエラーを出すことです。これに関しては標準が明確だと思います（？）。バグが発生するのは、関数が他の関数を呼び出し、その関数が間違った型をスローした場合のみです。 決定論的な組み込みCプログラムの世界から来た私は、関数が私に投げかけるものを正確に知ることを最も確実に好むでしょう。それをサポートする言語に何かがあれば、それを使用してみませんか？選択肢は次のようです： void func() throw(Egg_t); そして void func(); // This function throws an Egg_t 呼び出し元が2番目のケースでtry-catchを実装することを無視/忘れる可能性は大きいと思いますが、1番目のケースではそうではありません。 私が理解しているように、これら2つの形式のいずれかが突然別の種類の例外をスローすることにした場合、プログラムはクラッシュします。最初のケースでは、別の例外をスローすることが許可されていないため、2番目のケースでは、SpanishInquisition_tをスローすることを誰も期待していないため、その式は本来あるべき場所にキャッチされません。 後者の場合、プログラムの最高レベルで最後の手段としてcatch（...）を使用することは、プログラムクラッシュよりも優れているようには見えません。「ねえ、あなたのプログラムのどこかで、奇妙な未処理の例外がスローされました。 。 "。例外がスローされた場所から遠く離れると、プログラムを回復できません。できることは、プログラムを終了することだけです。 また、ユーザーの観点からは、OSから「プログラムが終了しました。アドレス0x12345のBlablabla」という悪意のあるメッセージボックス、またはプログラムから「未処理の例外：myclass」という悪意のあるメッセージボックスを受け取ったとしても、それほど気にすることはありませんでした。 …

50 c++  specifications  exceptions  exception-handling 

ラムダとデフォルトのメソッドインターフェースに関する新しいJava 8の機能に感謝します。それでも、私はまだチェックされた例外に飽きています。たとえば、オブジェクトのすべての表示フィールドを一覧表示するだけの場合は、単に次のように記述します。 Arrays.asList(p.getClass().getFields()).forEach( f -> System.out.println(f.get(p)) ); ただし、getメソッドはConsumerインターフェイスコントラクトに同意しないチェック例外をスローする可能性があるため、その例外をキャッチして次のコードを記述する必要があります。 Arrays.asList(p.getClass().getFields()).forEach( f -> { try { System.out.println(f.get(p)); } catch (IllegalArgumentException | IllegalAccessException ex) { throw new RuntimeException(ex); } } ); ただし、ほとんどの場合、例外をaとしてスローし、RuntimeExceptionコンパイルエラーなしで例外をプログラムに処理させるかどうかを許可します。 それで、私はチェックされた例外の迷惑のための私の物議を醸す回避策についてあなたの意見を持ちたいです。そのために、次のように補助インターフェイスConsumerCheckException<T>とユーティリティ関数rethrow（Dovalのコメントの推測に応じて更新）を作成しました。 @FunctionalInterface public interface ConsumerCheckException<T>{ void accept(T elem) throws Exception; } public class Wrappers { public static <T> Consumer<T> rethrow(ConsumerCheckException<T> c) …

49 java  functional-programming  exceptions  exception-handling  java8 

Javaの反復子の構文は次のとおりです（C＃の構文に似ています）。 Iterator it = sequence.iterator(); while (it.hasNext()) { System.out.println(it.next()); } 理にかなっています。Pythonの同等の構文は次のとおりです。 it = iter(sequence) while True: try: value = it.next() except StopIteration: break print(value) 例外は、例外的な状況でのみ使用されることになっていると思いました。 Pythonが例外を使用して反復を停止するのはなぜですか？

48 python  language-design  exceptions  iterator 

SonarQubeを使用してJavaコードを分析しますが、このルール（クリティカルに設定）があります。 パブリックメソッドは最大で1つのチェック済み例外をスローする必要があります チェック例外を使用すると、メソッド呼び出し元はエラーを伝播または処理することでエラーを処理します。これにより、これらの例外はメソッドのAPIの一部になります。 呼び出し元の複雑さを合理的に保つために、メソッドは複数の種類のチェック済み例外をスローするべきではありません。」 ソナーの別のビットにはこれがあります： パブリックメソッドは最大で1つのチェック済み例外をスローする必要があります チェック例外を使用すると、メソッド呼び出し元はエラーを伝播または処理することでエラーを処理します。これにより、これらの例外はメソッドのAPIの一部になります。 呼び出し元の複雑さを合理的に保つために、メソッドは複数の種類のチェック済み例外をスローするべきではありません。 次のコード： public void delete() throws IOException, SQLException { // Non-Compliant /* ... */ } 以下にリファクタリングする必要があります。 public void delete() throws SomeApplicationLevelException { // Compliant /* ... */ } オーバーライドするメソッドはこのルールによってチェックされず、いくつかのチェックされた例外をスローできます。 例外処理に関する私の読書でこの規則/推奨事項に出くわしたことは一度もなく、このトピックに関する標準、議論などを見つけようとしました。私が見つけた唯一のことはCodeRachからのこれです：メソッドは最大でいくつの例外をスローする必要がありますか？ これは広く受け入れられている標準ですか？

47 java  exceptions  static-analysis 

多くの現代言語は豊富な例外処理機能を提供していますが、AppleのSwiftプログラミング言語は例外処理メカニズムを提供していません。 私は例外に悩まされていますが、これが何を意味するのかを頭で悩ませています。Swiftにはアサーションがあり、もちろん戻り値があります。しかし、私は例外に基づいた考え方が例外なく世界にどのようにマップされるのかを想像するのに苦労しています（そのため、そのような世界が望ましい理由）。Swiftのような言語ではできないことはありますか？例外をなくすことで何かを得られますか？ たとえば、次のように表現するにはどうすればよいでしょうか try: operation_that_can_throw_ioerror() except IOError: handle_the_exception_somehow() else: # we don't want to catch the IOError if it's raised another_operation_that_can_throw_ioerror() finally: something_we_always_need_to_do() 例外処理のない言語（たとえば、Swift）で

47 language-design  exceptions  exception-handling  language-features  swift-language 

PHPのコンストラクターから例外をスローできることは知っていますが、それを行う必要がありますか？たとえば、パラメータの値が期待どおりではない場合。 または、メソッドが呼び出されるまで例外のスローを延期する必要があります。両方の場合の長所と短所は何ですか？

46 php  object-oriented  exceptions  exception-handling 

私は実際にかなり長い間それについて考えてきました。私は英語を母国語とする人ではありませんが、それでも何年もプログラミングの経験があり、常に私に尋ねました。なぜエラーとしてではなく例外として名前が付けられているのですか？ のPageNotFoundError代わりになりPageNotFoundExceptionます。

45 programming-languages  terminology  exceptions 

この質問は、例外処理をサポートするオブジェクト指向プログラミング言語に適用されることを意図しています。説明目的でのみC＃を使用しています。 通常、例外は、コードがすぐに処理できない問題が発生したときに発生catchし、別の場所（通常は外部スタックフレーム）の句でキャッチされることを目的としています。 Q：例外がスローおよびキャッチされず、メソッドから単純に返され、エラーオブジェクトとして渡される正当な状況はありますか？ この質問は、.NET 4のSystem.IObserver<T>.OnErrorメソッドが次のことを示唆しているために思いつきました。例外はエラーオブジェクトとして渡されます。 別のシナリオ、検証を見てみましょう。私が従来の知恵に従っているとしましょう。したがって、エラーオブジェクトタイプIValidationErrorと、ValidationException予期しないエラーの報告に使用される別の例外タイプを区別しています。 partial interface IValidationError { } abstract partial class ValidationException : System.Exception { public abstract IValidationError[] ValidationErrors { get; } } （System.Component.DataAnnotations名前空間は非常に似たようなことをします。） これらのタイプは次のように使用できます。 partial interface IFoo { } // an immutable type partial interface IFooBuilder // mutable counterpart to prepare instances of above type { …

45 exceptions  exception-handling 

MethodAはMethodBを呼び出し、MethodBはMethodCを呼び出します。 MethodBまたはMethodCには例外処理はありません。ただし、MethodAには例外処理があります。 MethodCでは、例外が発生します。 現在、この例外はMethodAにバブリングされており、適切に処理されます。 これの何が問題になっていますか？ 私の考えでは、ある時点で呼び出し元がMethodBまたはMethodCを実行し、それらのメソッドで例外が発生した場合、それらのメソッド内で例外を処理することで得られるものは、本質的にletではなくtry / catch / finallyブロックですそれらは呼び出し先までバブルアップしますか？ 例外処理に関するステートメントまたはコンセンサスは、それだけで実行が継続できない場合にスローすることです-例外。わかった。しかし、try / catchブロックを完全にダウンさせるのではなく、チェーンのさらに上で例外をキャッチしてください。 リソースを解放する必要があるときに理解しています。それはまったく別の問題です。

44 design-patterns  object-oriented-design  exceptions 

実行を停止してはならないいくつかのエラーを処理するためにerror、クライアントがチェックして例外をスローするために使用できる変数があります。これは反パターンですか？これを処理するより良い方法はありますか？この動作の例については、PHPのmysqli APIをご覧ください。可視性の問題（アクセサ、パブリックスコープとプライベートスコープ、クラス内の変数はグローバルですか？）が正しく処理されると仮定します。

44 design-patterns  object-oriented  exceptions  patterns-and-practices  anti-patterns 

Pythonでは、「許可を求める」（タイプ/条件チェック）よりも「許しを請う」（例外をキャッチする）の方が良いとよく耳にします。Pythonでのダックタイピングの強制に関して、これは try: x = foo.bar except AttributeError: pass else: do(x) より良いか悪い if hasattr(foo, "bar"): do(foo.bar) else: pass パフォーマンス、可読性、「pythonic」、またはその他の重要な要素の面で？

44 exceptions  python  duck-typing 

緯度/経度座標を表す構造体を作成しました。値の範囲は、経度では-180〜180、緯度では90〜-90です。 その構造体のユーザーがその範囲外の値を私に与えた場合、2つのオプションがあります： 例外をスロー（引数が範囲外） 値を制約に変換します -185の座標には意味があるため（極座標なので+175に非常に簡単に変換できます）、受け入れて変換できます。 例外をスローして、彼のコードが持つべきではない値をユーザーに与えたことをユーザーに伝える方が良いでしょうか？ 編集：緯度/経度と座標の違いも知っていますが、議論を簡単にするためにそれを単純化したかったのです。

42 c#  exceptions  validation