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

単独での例外処理に関する多くの有名なベストプラクティスがあります。「やるべきこと」は十分に知っていますが、大規模な環境でのベストプラクティスやパターンに関しては複雑になります。「早く投げて、遅れて捕まえる」-私は何度も聞いたことがありますが、それでも私を混乱させます。 低レベル層でNULLポインター例外がスローされる場合、なぜ早くスローしてキャッチする必要があるのですか？なぜ上位のレイヤーでキャッチする必要があるのですか？ビジネスレイヤーなど、高レベルで低レベルの例外をキャッチするのは意味がありません。各層の懸念に違反しているようです。 次の状況を想像してください。 数値を計算するサービスがあります。この数値を計算するために、サービスはリポジトリにアクセスして生データを取得し、他のサービスが計算を準備します。データ取得レイヤーで何か問題が発生した場合、なぜDataRetrievalExceptionをより高いレベルにスローする必要があるのですか？対照的に、CalculationServiceExceptionなどの意味のある例外に例外をラップすることをお勧めします。 なぜ早く投げ、なぜ遅くキャッチするのですか？

156 exception-handling 

これはアンチパターンですか？それは受け入れられる慣習ですか？ try { //do something } catch (Exception e) { try { //do something in the same line, but being less ambitious } catch (Exception ex) { try { //Do the minimum acceptable } catch (Exception e1) { //More try catches? } } }

95 anti-patterns  exception-handling 

プログラムの古典的な方法はtry ... catchです。tryなしで使用するのが適切なのはいつcatchですか？ Pythonでは、以下は正当であると思われ、意味をなします。 try: #do work finally: #do something unconditional ただし、コードはcatch何もしませんでした。同様に、Javaでは次のように考えることができます。 try { //for example try to get a database connection } finally { //closeConnection(connection) } 見た目が良く、突然例外の種類などを心配する必要はありません。これが良い習慣である場合、いつ良い習慣ですか？あるいは、これが良い習慣ではない、または合法でない理由は何ですか？（ソースをコンパイルしませんでした。Javaの構文エラーの可能性があるため、質問しています。Pythonが確実にコンパイルされることを確認しました。） 私が遭遇した関連する問題はこれです：私は関数/メソッドを書き続け、最後に何かを返さなければなりません。ただし、到達してはならない場所にある可能性があり、戻りポイントである必要があります。したがって、上記の例外を処理したとしてもNULL、コード内の到達すべきでないポイント（多くの場合はメソッド/関数の終わり）で、空の文字列を返すか、空のままにします。私は常にコードを再構築し、そうする必要がないようにしていますreturn NULL。なぜなら、それは絶対に良い習慣ではないように見えるからです。

79 java  python  exceptions  exception-handling 

同僚のコードを読んだところ、彼はさまざまな例外を頻繁にキャッチし、代わりに常に「RuntimeException」をスローすることがわかりました。これは非常に悪い習慣だといつも思っていました。私が間違っている？

70 java  exceptions  exception-handling 

約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 

多くの現代言語は豊富な例外処理機能を提供していますが、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 

この質問は、例外処理をサポートするオブジェクト指向プログラミング言語に適用されることを意図しています。説明目的でのみ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 

さまざまな言語（少なくともJava、C＃も考えますか）では、次のようなことができます if( condition ) singleStatement; while( condition ) singleStatement; for( var; condition; increment ) singleStatement; したがって、ステートメントが1つしかない場合、を使用して新しいスコープを追加する必要はありません{ }。try-catchでこれができないのはなぜですか？ try singleStatement; catch(Exception e) singleStatement; 常に新しいスコープなどを必要とするtry-catchについて特別なものはありますか？もしそうなら、コンパイラはそれを修正できませんでしたか？

38 exception-handling  scope  control-structures 

例： foobar = new InputStreamReader(p.getInputStream(), "ISO-8859-1"); エンコーディングはハードコーディングされており、正しいため、コンストラクターは仕様で宣言されたUnsupportedEncodingExceptionをスローしません（Java実装が壊れていない限り、この場合はとにかく失われます）。とにかく、Javaはとにかくその例外に対処することを強制します。 現在、そのように見えます try { foobar = new InputStreamReader(p.getInputStream(), "ISO-8859-1"); } catch(UnsupportedEncodingException e) { /* won't ever happen */ } それを改善する方法はありますか？

35 java  exception-handling 

例外に対するMaybe モナドの利点は何でしょうか？構文のMaybe明示的な（そしてかなりスペースを消費する）方法のように見えtry..catchます。 更新 Haskellについては意図的に言及していないことに注意してください。

34 language-agnostic  functional-programming  exceptions  exception-handling  monad 

Fortifyのような静的コードアナライザーは、finallyブロック内で例外がスローされる可能性があるときに「文句を言う」と言いUsing a throw statement inside a finally block breaks the logical progression through the try-catch-finallyます。通常、私はこれに同意します。しかし最近、私はこのコードに出くわしました： SomeFileWriter writer = null; try { //init the writer //write into the file } catch (...) { //exception handling } finally { if (writer!= null) writer.close(); } をwriter適切に閉じることができない場合、writer.close()メソッドは例外をスローします。（ほとんどの場合）ファイルは書き込み後に保存されなかったため、例外をスローする必要があります。 追加の変数を宣言し、閉じるときにエラーが発生した場合に設定しwriter、finallyブロックの後に例外をスローできます。しかし、このコードは正常に機能し、変更するかどうかはわかりません。 finallyブロック内で例外をスローすることの欠点は何ですか？

27 coding-style  exceptions  exception-handling 

一部の言語（C ++や初期バージョンのPHPなど）はfinally、try ... catch ... finally構成要素の一部をサポートしていません。でfinally、これまで必要？その中のコードは常に実行されるため、なぜ句のtry ... catchないブロックの後にそのコードを配置しない/しないのfinallyですか？なぜ使用するのですか？（私は、使用する/使用しない理由/動機を探しfinallyていますが、「キャッチ」をやめる理由や、そうすることが合法である理由ではありません。）

25 exception-handling 

Dao、サービス、コントローラーの3つのレイヤーのSpring Webアプリがあります。コントローラーはdaoを直接呼び出すことはなく、サービス層を介して呼び出します。現時点では、ほとんどの場合、処理されないdao例外（ランタイム）があると、エンドユーザーにエラーメッセージを表示するJSPによってキャッチされます。サービス層はすべてのdao例外をキャッチし、それらをサービス例外としてラップする必要がありますか？ try { daoInstance.someDaoMethod(); } catch(DataAccessException dae) { throw new ServiceException("message", dae); } ServiceExceptionもランタイムであり、どちらも処理されないと仮定しましょう。ServiceExceptionの代わりにDataAccessExceptionをスローするだけの違いはありますか？私は、プレゼンテーション層がデータアクセス例外を認識すべきでないと考えました。しかし、単にそれらをラップするだけで回復不能な例外をキャッチするポイントは見当たりません。

23 design-patterns  exception-handling  spring  dao