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

例外を使用して、コードのコンシューマーが予期しない動作を便利な方法で処理できるようにします。通常、例外は「発生した」シナリオを中心に構築されます- FileNotFound（指定したファイルが見つかりませんでした）またはZeroDivisionError（1/0操作を実行できませんでした）。 消費者の予想される動作を指定する可能性がある場合はどうなりますか？ たとえば、fetchHTTPリクエストを実行し、取得したデータを返すリソースがあるとします。そして、代わりのようなエラーServiceTemporaryUnavailableまたはRateLimitExceeded私達はちょうど引き上げるRetryableErrorそれだけで、要求を再試行する必要があり、特定の失敗を気にしないことを示唆している消費者を。そのため、基本的には呼び出し側にアクションを提案しています-「何をすべきか」。 消費者のすべてのユースケースを知っているわけではないため、これを頻繁に行うことはありません。しかし、それが発信者にとって最善のアクションコースを知っている特定のコンポーネントであると想像してください。

19 exceptions 

例外クラスで例外の接尾辞を指定すると、コードの匂いがします（冗長な情報-名前の残りの部分はエラー状態を意味し、例外から継承されます）。しかし、それは誰もがそれをしているようで、良い習慣のようです。 私はこれが良い習慣である理由を理解したいと思っています。 私はすでに例外がクラス名に接尾辞例外を持っているのはなぜかという質問を見てきました 質問はPHPに対するものであり、応答はおそらくJavaに対して有効です。他の引数はありますか、それとも明示的に区別するのと同じくらい簡単ですか？ 前の質問の例を取り上げると、FileNoFound例外ではない名前のクラスが実際にjavaにあるでしょうか？可能であれば、接尾辞を付ける必要がありExceptionますか？ の日食の簡単な階層を見るとException、確かに、それらの大部分は例外の接尾辞を持っていますが、いくつかの例外があります。javassist例えば-接尾辞なしでいくつかの例外を持っていると思われるライブラリの一例であるBadByteCode、BadHttpRequestなど BouncyCastle のような例外を持つ別のライブラリです CompileError 私はこの問題に関する情報がほとんどないので、少しグーグルで調べました。

19 java  naming  exceptions 

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

18 bug  debugging  issue-tracking  exceptions  exception-handling 

ユニットテストを行っています。 1つの機能をテストしようとしています。 テストコンポーネントから呼び出します。しかし、リモート関数が例外を処理できない場合、テスターコンポーネントも例外を取得します。 テスターコンポーネントで例外が発生することを心配する必要がありますか？ ありがとう。 編集： PS： エラーを投げることは良いことですが、最後の選択肢になるまでエンドユーザーにではなく、他の機能に対してのみです！ OMG私はプログラミングの見積もりを書きました!!

18 testing  unit-testing  exceptions 

try / catchの周りにすべてのコードブロックを散らかすのではなく、中央の場所またはプロセスの境界で例外を処理することの重要性が良いプラクティスとして強調されているいくつかの投稿を見ることができます。私たちのほとんどはそれの重要性を理解していると強く信じていますが、主に例外中のトラブルシューティングを容易にするために、より多くのコンテキスト固有の情報（例：メソッドパラメータ合格）、方法はtry / catch / log / rethrowの周りにメソッドをラップすることです。 public static bool DoOperation(int num1, int num2) { try { /* do some work with num1 and num2 */ } catch (Exception ex) { logger.log("error occured while number 1 = {num1} and number 2 = {num2}"); throw; } } 例外処理の優れた実践を維持しながら、これを達成する正しい方法はありますか？このためにPostSharpのようなAOPフレームワークについて聞いたことがありますが、これらのAOPフレームワークに関連するマイナスまたは主要なパフォーマンスコストがあるかどうかを知りたいです。 ありがとう！

18 c#  exceptions  patterns-and-practices  logging 

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

17 java  scala  exceptions  exception-handling 

少し前に、Javaの代わりにScalaを使い始めました。私にとって言語間の「変換」プロセスの一部は、Either（チェックされた）Exceptions の代わりにs を使用することを学ぶことでした。私はしばらくこの方法でコーディングしてきましたが、最近、それが本当に良い方法かどうか疑問に思い始めました。 1つの大きな利点Eitherは、Exceptionパフォーマンスの向上です。Exceptionスタックトレースを構築する必要があり、スローされています。ただし、私が理解している限りでは、投げることExceptionは難しい部分ではありませんが、スタックトレースを構築することは重要です。 しかし、その後、常にを使用してExceptionsを構築/継承することができます。scala.util.control.NoStackTraceさらにEither、実際にはの左側が実際にException（パフォーマンスブーストを控える）であるケースがたくさんあります。 もう1つの利点Eitherは、コンパイラの安全性です。ScalaコンパイラExceptionは、（Javaのコンパイラとは異なり）ハンドルされていないs について文句を言いません。しかし、私が間違っていなければ、この決定は、このトピックで議論されているのと同じ推論で推論されます。 構文の面では、Exception-styleの方がはるかに明確だと感じています。次のコードブロックを調べます（どちらも同じ機能を実現しています）。 Either スタイル： def compute(): Either[String, Int] = { val aEither: Either[String, String] = if (someCondition) Right("good") else Left("bad") val bEithers: Iterable[Either[String, Int]] = someSeq.map { item => if (someCondition(item)) Right(item.toInt) else Left("bad") } for { a <- aEither.right bs <- reduce(bEithers).right ignore …

17 coding-style  exceptions  scala  either 

isocpp.org例外よくある質問の状態 関数の使用におけるコーディングエラーを示すために、throwを使用しないでください。assertまたはその他のメカニズムを使用して、プロセスをデバッガーに送信するか、プロセスをクラッシュさせて開発者がデバッグするためのクラッシュダンプを収集します。 一方、標準ライブラリはstd :: logic_errorとそのすべての派生物を定義します。これらは、他のことに加えてプログラミングエラーを処理することになっているように思えます。プログラミングエラーではなく、空の文字列をstd :: stof（invalid_argumentをスローします）に渡しますか？「1」/「0」以外の文字を含む文字列をプログラミングエラーではなくstd :: bitset（invalid_argumentをスローします）に渡しますか？プログラミングエラーではなく、無効なインデックス（out_of_rangeをスローします）でstd :: bitset :: setを呼び出していますか？そうでない場合、テストするプログラミングエラーは何ですか？std :: bitset文字列ベースのコンストラクタはC ++ 11以降にのみ存在するため、例外の慣用的な使用を念頭に置いて設計されている必要があります。一方、logic_errorは基本的にまったく使用すべきではないと言われました。 例外が頻繁に発生する別のルールは、「例外的な状況でのみ例外を使用する」です。しかし、ライブラリ関数はどのような状況が例外的であるかをどのように認識するのでしょうか？一部のプログラムでは、ファイルを開けないことは例外です。他の人にとっては、メモリを割り当てることができないことは例外ではないかもしれません。そして、その間に何百ものケースがあります。ソケットを作成できませんか？接続できない、またはソケットまたはファイルにデータを書き込むことができませんか？入力を解析できませんか？例外的かもしれませんが、そうでないかもしれません。関数自体は、一般的に間違いなく知ることができず、どの種類のコンテキストが呼び出されているのかわかりません。 だから、特定の機能に例外を使用するかどうかをどのように決定するのですか？実際には一貫性のある唯一の方法は、すべてのエラー処理に使用するか、または何もしないことです。標準ライブラリを使用している場合、その選択は私のために行われました。

16 design  c++  exceptions 

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

16 exceptions  exception-handling 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 閉じた3年前。 play（）メソッドとstop（）メソッドを持つMediaPlayerクラスがあるとします。playメソッドが以前に呼び出されていない場合にstopメソッドを実装するときに使用する最適な戦略は何ですか。2つのオプションがあります。プレーヤーが適切な状態にないために例外をスローするか、stopメソッドの呼び出しを静かに無視します。 ある状況でメソッドが呼び出されることは想定されていないが、その実行がプログラム全般に害を及ぼさない場合の一般的なルールは何でしょうか？

16 exceptions  methods  state 

私は数か月間アプリケーションを構築していましたが、次のようなパターンが明らかになりました。 logger.error(ERROR_MSG); throw new Exception(ERROR_MSG); または、キャッチする場合： try { // ...block that can throw something } catch (Exception e) { logger.error(ERROR_MSG, e); throw new MyException(ERROR_MSG, e); } したがって、例外をスローまたはキャッチするたびに、ログに記録します。実際、それはアプリケーションで行ったほとんどすべてのロギングでした（アプリケーションの初期化のための何かに加えて）。 それで、プログラマーとして、私は繰り返しを避けます。そこで、ロガー呼び出しを例外構築に移動することにしました。そのため、例外を構築するたびに、ログが記録されます。確かに、私のために例外をスローするExceptionHelperを作成することもできますが、それはコードの解釈を難しくし、さらに悪いことに、コンパイラはそれをうまく処理できず、そのメンバーへの呼び出しがすぐに投げます。 それで、これはアンチパターンですか？もしそうなら、なぜですか？

15 exceptions  logging 

私の最初の「深刻な」C ++ライブラリを設計するとき、私は次のことを自問しています： 例外を派生させるのは良いスタイルstd::exceptionですか？それは子孫ですか？！ 読んだ後でも 例外クラスの設計 ライブラリに実装する「良い数」の例外とは何ですか？ まだわかりません。というのは、一般的な（ただし、良くないかもしれない）プラクティスに加えて、ライブラリユーザーとしてstd::exception、ライブラリ実装で標準ライブラリ関数が失敗した場合にのみライブラリ関数がs をスローし、それについて何もできないと仮定するからです。しかし、それでも、アプリケーションコードを記述するとき、私にとっては非常に便利であり、また、単にをスローするだけでも見栄えが良いstd::runtime_errorです。また、私のユーザーは、定義された最小限のインターフェース（what()コードやコードなど）に依存することもできます。 また、たとえば、ユーザーが誤った引数を指定した場合、をスローするよりも便利なのは何std::invalid_argumentですか？だから、std :: exceptionのまだ一般的な使用と組み合わせて、他のコードで見ます：さらに進んで、カスタム例外クラス（例えばlib_foo_exception）から、そしてから派生してみませんかstd::exception。 考え？

15 c++  exceptions 

StackOverflowExceptionについてMSDNから引用： ネストされたメソッド呼び出しが多すぎるために実行スタックがオーバーフローしたときにスローされる例外。 Too manyここはかなりあいまいです。多すぎると本当に多すぎることをどのようにして知ることができますか？何千もの関数呼び出し？何百万人？私はそれが何らかの形でコンピュータのメモリの量に関係しているに違いないと思いますが、大体正確な大きさのオーダーを考え出すことは可能ですか？ 再帰構造と再帰関数呼び出しを多用するプロジェクトを開発しているので、これが心配です。ほんの小さなテスト以上に使用し始めたときに、アプリケーションが失敗するのは望ましくありません。

15 .net  exceptions  recursion  stackoverflow 

NotImplementedExceptionあなたがまだ書いていないコードを投げることは悪い習慣と考えられていますか？おそらくTODOコメントはより安全だと考えられますか？

15 .net  comments  coding  exceptions 

私はかなり大きなWebアプリをリファクタリングしています。主な問題の1つは、一貫性のないエラー処理であり、私は賢明な戦略を考え出そうとしています。set_error_handlerを介して、基本的にErrorExceptionsの PHPエラーを変換するカスタムエラーハンドラーと、Exceptionから直接継承するカスタムベース例外クラスを作成しました。 実稼働環境では、set_exception_handlerを介して汎用の例外catch-allを使用しており、例外ログ*をミックスに追加しようとしています。私のジレンマは、基本例外クラスまたはキャッチオールで実際のロギングを行う場所です。 私はそれをキャッチオールに記録するいくつかの理由を考えました： 基本例外クラスの適切な子に変換する必要があるコードには、かなりの数の例外があります。それが起こるまで、すべての例外がログに記録されるわけではありません。 キャッチオールでそれを行う方が自然な感じがします。ベース例外クラスはそれ以上のことをすべきではありません。（それは単一の責任原則のことかもしれませんが、見当違いの感覚かもしれません） 基本例外クラスにログインする1つの理由： 現在、キャッチオールは本番環境でのみ使用されています。他の環境（開発、テスト）で導入するのは簡単ですが、エラーは環境ごとに処理が異なるため、本番環境では404/503エラーページに変換されるため、いくつかの調整が必要になります。 例外をログに記録する場所について、受け入れられるプラクティスはありますか？ *ロギングには最初はテキストファイルへの書き込みが含まれますが、特定の種類の例外のメールを送信するように進化する場合があります。 @unholysamplerの答えに促されたいくつかの説明： 私は2 * 10 ^ 6のslocコードベースに直面しており、多くのサードパーティのものを制御できません。また、PHPの前日例外を制御するコードの一部もあります。また、最近のくだらないコードもいくつかあります。私たちは、思考をやめ、ハッキングされなければならなかった激しいプレッシャーから長期間回復しています。 すべての矛盾に対処し、適切なエラー処理アプローチを導入するために積極的にリファクタリングを行っていますが、それには時間がかかります。エラーが適切に処理されるようになるまで、どうすればいいのか興味があります。おそらく、ある時点で賢明な例外戦略について別の質問をするでしょう。 ロギングの背後にある主な動機は、本番環境で何か悪いことが起こったときに電話でメールを受け取ることです。データダンプが巨大になるかどうかは気にしません。データダンプが大きくなると、古いジョブを時々削除するcronジョブが必要になります。

15 php  exceptions  logging