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

メソッドのパラメーターを反復処理するforeachループ内ですべてのロジックが実行されるメソッドがあります。 public IEnumerable<TransformedNode> TransformNodes(IEnumerable<Node> nodes) { foreach(var node in nodes) { // yadda yadda yadda yield return transformedNode; } } この場合、空のコレクションを送信すると空のコレクションになりますが、それは賢明ではないのでしょうか。 ここでの私のロジックは、誰かがこのメソッドを呼び出している場合、データを渡すことを意図し、誤った状況でのみ空のコレクションをメソッドに渡すことです。 この動作をキャッチして例外をスローする必要がありますか、空のコレクションを返すのがベストプラクティスですか？

40 c#  exceptions  collections  parameters 

ではCの上にC ++、およびC ++の上にCを使用する場合は？ステートメントがあります。コードサイズ/ C ++例外： ジェリーの回答（他の点の中でも）： （...）C ++で本当に小さな実行可能ファイルを生成することはより困難になる傾向があります。本当に小さなシステムでは、とにかく大量のコードを書くことはめったにありませんし、余分な（...） なぜそうなるのかを尋ねたところ、ジェリーは答えました。 主なことは、C ++には例外処理が含まれていることです（少なくとも通常は）実行可能ファイルのサイズに最小値が追加されます。ほとんどのコンパイラでは例外処理を無効にできますが、結果を実行するとC ++になりません。（...） 技術的な現実世界のレベルで私は本当に疑っていません。 したがって、プロジェクトが言語としてC ++を選択し、例外を無効にすることを選択した実世界の例を聞くことに興味があります（純粋に好奇心から）。（ユーザーコードで単に例外を「使用しない」だけでなく、コンパイラーで例外を無効にして、例外をスローまたはキャッチできないようにします。）プロジェクトがそうすることを選択した理由例外）-（技術的な）理由は何ですか？ 補遺：回答を詳しく説明したい場合は、例外なしの意味がどのように処理されるかを詳しく説明するとよいでしょう。 STLコレクション（vector、...）は正常に動作しません（割り当てエラーは報告できません） new 投げられない コンストラクターが失敗することはありません

40 c++  exceptions 

私たちはシステムを立ち上げており、時々NullReferenceExceptionメッセージで有名な例外を受け取りますObject reference not set to an instance of an object。 しかし、ほぼ20個のオブジェクトがあるメソッドでは、オブジェクトがnullであると言うログを持つことは、まったく役に立ちません。あなたがセミナーの警備員であるとき、100人の出席者のうちの1人がテロリストであるとあなたに言うようなものです。それは本当にあなたにはまったく役に立ちません。どの男が脅迫的な男であるかを検出したい場合は、より多くの情報を取得する必要があります。 同様に、バグを削除する場合は、どのオブジェクトがnullであるかを知る必要があります。 今、何かが私の心を数ヶ月の間取りつづけています、そしてそれは： なぜ.NETから名前、または少なくともオブジェクト参照のタイプが提供されないのですか？。リフレクションまたは他のソースからタイプを理解できませんか？ また、どのオブジェクトがnullであるかを理解するためのベストプラクティスは何ですか？これらのコンテキスト内のオブジェクトのNULL可能性を常に手動でテストし、結果をログに記録する必要がありますか？もっと良い方法はありますか？ 更新： 例外The system cannot find the file specifiedは同じ性質を持っています。プロセスにアタッチしてデバッグするまで、どのファイルを見つけることができません。これらのタイプの例外はよりインテリジェントになる可能性があると思います。.NETがc:\temp.txt doesn't exist.その一般的なメッセージの代わりに私たちに伝えることができたらもっと良いと思いませんか？開発者として、私は賛成票を投じます。

39 .net  exceptions  logging  null 

多くの場合、関数を書くときは、そのようなエラーをできるだけ早く検出するために、入力を有効にする必要があります（これらは前提条件と呼ばれます）。前提条件が失敗すると、常に例外がスローされます。しかし、これがベストプラクティスであるかどうか、そしてそうでない場合はアサーションがより適切かどうかを疑い始めています。 それで、いつアサーションを使用するのが適切であり、いつ例外をスローするのが適切であるのか、どちらを行う必要がありますか？

38 exceptions  assertions 

昨日投稿を読んで、私は例外の起源についてあまり知らないことに気付きました。OOP関連の概念のみですか？私はそう思う傾向がありますが、やはりデータベースの例外があります。

37 programming-languages  exceptions 

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

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

私はNotImplementedError実装したい任意のメソッドに対してaを上げるのが好きですが、まだそれをやろうとしていません。私はすでに部分的な実装を持っているかもしれraise NotImplementedError()ませんが、まだ気に入らないのでそれを前に付けます。一方で、他の人が自分のコードを保守しやすくするので、慣習に固執するのも好きです。そして、慣習は正当な理由で存在するかもしれません。 ただし、NotImplementedErrorのPythonドキュメントには次のように記載されています。 この例外はRuntimeErrorから派生しています。ユーザー定義の基本クラスでは、派生クラスがメソッドをオーバーライドする必要がある場合、抽象メソッドはこの例外を発生させる必要があります。 これは、私が説明したものよりもはるかに具体的で正式なユースケースです。NotImplementedErrorAPIのこの部分が進行中の作業であることを単に示すためにを上げるのは良い、従来のスタイルですか？そうでない場合、これを示す別の標準化された方法はありますか？

34 python  development-process  exceptions 

私はチームのリーダーに、bool isSuccessfulまたはenumをエラーコードとともに返す代わりに、C ++で例外を使用できるように説得しようとしています。しかし、私は彼のこの批判に対抗することはできません。 このライブラリを検討してください。 class OpenFileException() : public std::runtime_error { } void B(); void C(); /** Does blah and blah. */ void B() { // The developer of B() either forgot to handle C()'s exception or // chooses not to handle it and let it go up the stack. C(); …

33 c++  exceptions 

コードレビューの後、デザインの選択について議論したところです。あなたの意見は何でしょうか。 このPreferencesクラスは、キーと値のペアのバケットです。NULL値は正当です（重要です）。特定の値がまだ保存されていない可能性があり、要求されたときに事前定義されたデフォルト値で初期化することにより、これらのケースを自動的に処理したいと考えています。 説明したソリューションでは、次のパターンを使用しました（注：これは実際のコードではなく、明らかに-説明のために単純化されています）。 public class Preferences { // null values are legal private Map<String, String> valuesFromDatabase; private static Map<String, String> defaultValues; class KeyNotFoundException extends Exception { } public String getByKey(String key) { try { return getValueByKey(key); } catch (KeyNotFoundException e) { String defaultValue = defaultValues.get(key); valuesFromDatabase.put(key, defaultvalue); return defaultValue; } …

33 java  programming-practices  coding-style  exceptions  anti-patterns 

問題： 長い間、私はexceptionsメカニズムが本当に何をすべきかを実際には解決しないと感じているため、メカニズムについて心配しています。 クレーム：このトピックについては長い議論があり、それらのほとんどはexceptionsエラーコードの比較と返送に苦労しています。これは間違いなくここのトピックではありません。 エラーを定義しようとすると、Bjarne Stroustrup＆Herb SutterのCppCoreGuidelinesに同意します エラーは、関数が公示された目的を達成できないことを意味します クレーム：exceptionメカニズムは、エラーを処理するための言語セマンティックです。 クレーム：私には、タスクを達成しないための機能には「言い訳」がありません：機能が結果を保証できないように事前/事後条件を誤って定義したか、開発に時間を費やすために特定の例外的なケースが十分に重要ではないと考えられます解決策。IMOでは、通常のコードとエラーコードの処理の違いは（実装前に）非常に主観的なものだと考えています。 クレーム：例外を使用して、事前または事後条件が維持されていないことを示すことはexception、主にデバッグの目的で、メカニズムの別の目的です。私はexceptionsここのこの使用法をターゲットにしません。 多くの書籍、チュートリアル、およびその他のソースでは、エラー処理は非常に客観的な科学として示される傾向がexceptionsありますが、それは解決され、catchあらゆる状況から回復できる堅牢なソフトウェアが必要です。しかし、開発者としての数年間は、別のアプローチから問題を見るようになりました。 プログラマは、特定のケースがあまりにもまれに慎重に実装できないと思われる場合に例外をスローすることにより、タスクを単純化する傾向があります。この典型的なケースは次のとおりです。メモリ不足の問題、ディスクの空き容量の問題、破損したファイルの問題など。これで十分かもしれませんが、必ずしもアーキテクチャレベルから決定されるわけではありません。 プログラマは、ライブラリの例外に関するドキュメントを注意深く読んでいない傾向があり、通常、関数がスローするタイミングとタイミングを認識していません。さらに、たとえ知っていても、実際には管理していません。 プログラマーは、十分早くに例外をキャッチしない傾向があります。そして、それらをキャッチする場合、ほとんどの場合、ログに記録してさらにスローします。（最初のポイントを参照）。 これには2つの結果があります。 頻繁に発生するエラーは、開発の初期段階で検出され、デバッグされます（これは良いことです）。 まれな例外は管理されず、ユーザーのホームでシステムがクラッシュします（素敵なログメッセージが表示されます）。エラーが報告される場合もあれば、そうでない場合もあります。 それを考慮すると、IMOのエラーメカニズムの主な目的は次のとおりです。 特定のケースが管理されていないコードで可視化する。 この状況が発生した場合、問題のランタイムを関連コード（少なくとも呼び出し元）に伝えます。 回復メカニズムを提供します exceptionエラー処理メカニズムとしてのセマンティックの主な欠陥はIMOです。throwソースコードのどこにa があるかは簡単にわかりますが、宣言を見ることで特定の関数がスローできるかどうかはわかりません。これは、上で紹介したすべての問題をもたらします。 言語は、言語の他の側面（たとえば、強力なタイプの変数）の場合ほど厳密にエラーコードを適用およびチェックしません。 解決策を試す これを改善するために、非常に単純なエラー処理システムを開発しました。これは、通常のコードと同じレベルのエラー処理をエラー処理にしようと試みます。 アイデアは次のとおりです。 各（関連する）関数は、success非常に軽いオブジェクトへの参照を受け取り、場合によってはエラー状態に設定することがあります。オブジェクトは、テキスト付きのエラーが保存されるまで非常に軽いです。 提供されたオブジェクトに既にエラーが含まれている場合、関数はそのタスクをスキップすることが推奨されます。 エラーを無効にしないでください。 完全な設計では、明らかに各側面（約10ページ）を徹底的に検討し、OOPへの適用方法も検討します。 Successクラスの例： class Success { public: enum SuccessStatus { ok = 0, // All is fine error = 1, // …

31 c++  coding-style  exceptions  paradigms 

イテレーターの作成の一環として、次のコードを作成していることに気付きました（エラー処理を削除） public T next() { try { return next; } finally { next = fetcher.fetchNext(next); } } 読むよりもやや読みやすい public T next() { T tmp = next; next = fetcher.fetchNext(next); return tmp; } 私はそれが読みやすさの違いがそれほど圧倒的ではないかもしれない単純な例であることを知っていますが、例外が含まれていないこのような場合にtry-finallyを使用するのが悪いかどうかについての一般的な意見に興味がありますコードを簡素化するときに実際に優先される場合。 悪い場合：なぜ？スタイル、パフォーマンス、落とし穴、...？ 結論 あなたのすべての答えに感謝します！（少なくとも私にとって）結論は、最初の例は一般的なパターンであれば読みやすかったかもしれないが、そうではないということだと思います。そのため、目的外の構造を使用することで生じる混乱と、場合によっては難読化された例外フローが、単純化よりも重要になります。

30 java  code-quality  exceptions  readability 

デスクトップアプリケーションで未処理の例外が発生した場合のベストプラクティスは何ですか？ ユーザーがサポートに連絡できるように、ユーザーにメッセージを表示しようと考えていました。ユーザーにアプリケーションを再起動することをお勧めしますが、強制することはしません。ここで説明しているものと同様：ux.stackexchange.com-予期しないアプリケーションエラーを処理する最良の方法は何ですか？ プロジェクトは.NET WPFアプリケーションであるため、説明されている提案は次のようになります（これは簡略化された例です。ユーザーが[詳細の表示]をクリックして、エラーを簡単に報告してください）： public partial class App : Application { public App() { DispatcherUnhandledException += OnDispatcherUnhandledException; } private void OnDispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e) { LogError(e.Exception); MessageBoxResult result = MessageBox.Show( $"Please help us fix it and contact support@example.com. Exception details: {e.Exception}" + "We recommend to restart the application. " + …

30 c#  architecture  .net  exceptions  fail-fast 

私はかつて、C ++プログラムが最終的にすべての例外をキャッチする必要があるとアドバイスされました。当時与えられた理由は、本質的に、例外がmain()奇妙なゾンビ状態に入る以外にバブルするプログラムです。これは数年前に話されましたが、振り返ってみると、観察された現象は、問題のプロジェクトからの非常に大きなコアダンプの長期にわたる生成によるものだと思います。 当時、これは奇妙だが説得力があるように思われた。C ++がすべての例外をキャッチしていないことをプログラマに「罰」するのはまったく無意味でしたが、私の前の証拠がこれを裏付けているようです。問題のプロジェクトでは、キャッチされていない例外をスローしたプログラムは奇妙なゾンビ状態に入ったように見えます-または、私が原因だと思うように、不要なコアダンプの中でのプロセスを停止するのは異常に困難です。 （なぜこれが当時より明白ではなかったのか疑問に思う人のために：プロジェクトは複数のプロセスから複数のファイルに大量の出力を生成し、あらゆる種類のaborted (core dumped)メッセージを事実上不明瞭にしました。プログラムの問題は通常、長期間のプログラムによって長時間にわたって多くのイベントから蓄積された状態に依存するのではなく、短期間のプログラムへの初期入力に依存していませんでした（< 1時間）したがって、デバッグビルドまたはデバッガーからの同じ入力でプログラムを再実行するだけで、より詳細な情報を取得することがより実用的でした。） 現在、例外を残すことを防ぐためだけに例外をキャッチすることの大きな利点または欠点があるかどうかはわかりませんmain()。 例外が過去に発生することを許可することで考えられる小さな利点main()は、結果がstd::exception::what()端末に出力されることです（少なくともLinuxでgccコンパイルされたプログラムの場合）。一方、これは代わりに、すべての例外をキャッチすることによって達成することは簡単ですから派生std::exceptionし、その結果を印刷std::exception::what()し、それが由来していない例外からのメッセージ印刷することが望ましいならstd::exception、それはその後、しなければならない出発前にキャッチされmain()、印刷するためにはメッセージ。 過去に例外が発生することを許可することで考えられるささいな欠点main()は、不要なコアダンプが生成される可能性があることです。大量のメモリを使用するプロセスの場合、これは非常に厄介であり、プログラムからコアダンプ動作を制御するにはOS固有の関数呼び出しが必要です。一方、コアダンプと終了が必要な場合は、代わりにを呼び出すstd::abort()ことでいつでも達成でき、コアダンプなしの終了はを呼び出すことでいつでも達成できますstd::exit()。 逸話的に、what(): ...クラッシュ時に広く配布されているプログラムによって出力されるデフォルトのメッセージを見たことはありません。 C ++例外が過去にバブルアップすることを許可または拒否する強力な議論は、もしあれば、何main()ですか？ 編集：このサイトには、一般的な例外処理に関する質問がたくさんあります。私の質問は、特に処理できないC ++の例外に関するものでmain()、エラーメッセージが出力される可能性はありますが、すぐにエラーが表示されることがあります。

29 c++  exceptions 

例外を使用して問題を早期に発見します。例えば： public int getAverageAge(Person p1, Person p2){ if(p1 == null || p2 == null) throw new IllegalArgumentException("One or more of input persons is null"). return (p1.getAge() + p2.getAge()) / 2; } 私のプログラムはnullこの関数を決して渡すべきではありません。私はそれをするつもりはありません。しかし、私たち全員が知っているように、プログラミングでは意図しないことが起こります。 この問題が発生した場合に例外をスローすると、プログラムの他の場所でさらに問題が発生する前に、それを見つけて修正することができます。例外はプログラムを停止し、「ここで悪いことが起こったので修正してください」と言っています。これnullがプログラム内を移動する代わりに、他の場所で問題を引き起こします。 さて、あなたは正しいです。この場合、これはただちにすぐにnull発生するNullPointerExceptionため、最良の例ではないかもしれません。 しかし、たとえば次のような方法を検討してください。 public void registerPerson(Person person){ persons.add(person); notifyRegisterObservers(person); // sends the person object to all kinds of …

29 programming-practices  exceptions  error-handling 

今日でも、プロのチームによって構築された、長年使用されてきた製品が、今日までまだ、ユーザーに役立つエラーメッセージを提供できないことに驚かされます。場合によっては、ほんの少しの追加情報を追加するだけで、ユーザーの時間を節約できます。 エラーを生成するプログラムが、何らかの理由で生成しました。何が失敗したのか、ユーザーにできる限り多くの情報を提供するために、すべてを自由に使用できます。それでも、ユーザーを支援する情報を提供することは優先度が低いようです。これは大きな失敗だと思います。 1つの例はSQL Serverからのものです。使用中のデータベースを復元しようとすると、まったく問題が発生します。SQL Serverは、どのプロセスとアプリケーションがそれにアクセスしているかを知っています。データベースを使用しているプロセスに関する情報を含めることができないのはなぜですか？すべての人がApplicatio_Name接続文字列で属性を渡すわけではないことは知っていますが、問題のマシンに関するヒントさえあれば役立つかもしれません。 別の候補であるSQL Server（およびmySQL）は、美しいstring or binary data would be truncatedエラーメッセージと同等のものです。多くの場合、生成されたSQLステートメントの単純な閲覧と、テーブルが原因の列を示します。これは常に当てはまるわけではありません。データベースエンジンがエラーを検出した場合、なぜその時間を節約できず、どの列が壊れているかを教えてくれないのでしょうか。この例では、それをチェックするとパフォーマンスが低下する可能性があり、これがライターを妨げると主張できます。結構です、私はそれを買います。データベースエンジンは、エラーがあることを認識すると、格納される値と列の長さを事後比較します。次に、それをユーザーに表示します。 ASP.NETの恐ろしいテーブルアダプタも有罪です。クエリを実行し、どこかで制約に違反していることを示すエラーメッセージを表示できます。ありがとう。開発者は行番号やサンプルデータを提供するのが面倒なので、データモデルとデータベースを比較する時間です。（記録のために、私は選択によってこのデータアクセス方法を決して使用しませんでした、それはただ私が継承したプロジェクトです！）。 C＃またはC ++コードから例外をスローするたびに、手元にあるすべてのものをユーザーに提供します。それを投げる決定が下されたので、私が提供できる情報が多ければ多いほど良いです。関数が例外をスローしたのはなぜですか？何が渡され、何が期待されましたか？例外メッセージの本文に意味のあるものを入れるには少し時間がかかります。地獄、それは何もしませんが、私のコードは意味のあるものを投げることを知っているので、私が開発する間、私を助けます。 複雑な例外メッセージをユーザーに表示すべきではないと主張することができます。私はそれに反対しますが、それはあなたのビルドに応じて異なるレベルの冗長性を持つことで簡単になだめることができる議論です。それでも、ASP.NETおよびSQL Serverのユーザーは一般的なユーザーではなく、問題をより迅速に追跡できるため、冗長でおいしい情報に満ちたものを好むでしょう。 開発者がエラーが発生したときに最低限の情報を提供することは、この日と年齢で大丈夫だと思うのはなぜですか？ それは2011年の男だ、来るで。

29 design  exceptions  error-messages