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

私は「Learning Python」を読んでいて、次のことに出くわしました。 ユーザー定義の例外は、エラー以外の条件を通知することもできます。たとえば、呼び出しルーチンが解釈するためのステータスフラグを返す代わりに、一致が見つかったときに例外を発生させるように検索ルーチンをコーディングできます。以下では、try / except / else例外ハンドラーがif / else戻り値テスターの作業を行います。 class Found(Exception): pass def searcher(): if ...success...: raise Found() # Raise exceptions instead of returning flags else: return Pythonは動的に型付けされ、コアに対してポリモーフィックであるため、このような状態を通知するには、センチネルの戻り値ではなく例外が一般的に推奨される方法です。 この種のことはさまざまなフォーラムで何度も議論され、StopIterationを使用してループを終了するPythonへの参照は何度も見ましたが、公式のスタイルガイドにはあまり見当たりません（PEP 8にはフロー制御の例外への参照があります）または開発者からの声明。これがPythonのベストプラクティスであると述べる公式なものはありますか？ これ（制御フローとしての例外は深刻なアンチパターンと見なされますか？その場合、なぜ？）には、このスタイルがPythonicであるとコメントするコメントもあります。これは何に基づいていますか？ TIA

15 python  programming-practices  exceptions 

私は常にこれに取り組んでいます... try / catchingと、ホットポテトのようにコールスタックにスローバックされるタブ、ブラケット、例外のこのわいせつな混乱にならないコードとの適切なバランスを見つけようとしています。たとえば、SQLiteを使用する現在開発中のアプリがあります。SQLite呼び出しを抽象化するデータベースインターフェイスと、データベースに出入りするものを受け入れるモデルがあります。したがって、SQLite例外が発生した場合は、モデル（呼び出し元）に投げ込まれます。 ）、AddRecord / DeleteRecord / whateverを呼び出した人に渡す必要がある人... エラーコードを返すとは対照的に、エラーコードがなど、忘れられ、無視することができますので、私は（許可され、私は例外は基本的に処理する必要があるのに対し、例外のファンだ可能性があり、私はよ...キャッチし、すぐに移動します）確かに、私が今していることよりも良い方法があるはずです。 編集： 私はこれを少し異なって表現する必要がありました。私は異なるタイプなどとして再スローすることを理解しています。私の質問は...そうするとき、どのようにコードをきれいに保つのが最善ですか？しばらくすると、私にとって非常に混乱し始めます。

15 code-quality  exceptions  readability  clean-code 

デフォルトのコンストラクターについて具体的に尋ねる コンストラクターがオブジェクトのすべてのデータを初期化する場合、適切な初期化なしでは使用できないクラスを作成すると、デフォルトのコンストラクターが役に立たなくなるわけではありませんか？考慮してください： // 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 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 Javaのチェックされた例外は、長年にわたっていくつかの悪い報道を受けています。わかりやすい兆候は、それが文字通り世界で唯一の言語であることです（GroovyやScalaのような他のJVM言語でさえも）。SpringやHibernateなどの著名なJavaライブラリもそれらを使用しません。 私は個人的に（レイヤー間のビジネスロジックで）それらの1つの用途を見つけましたが、そうでなければ私はかなりアンチチェックされた例外です。 私が気付いていない他の用途はありますか？

14 java  exceptions  errors 

例外がどのように動作し、C＃で例外をキャッチして処理する方法を理解していますが、例外が正しくキャッチされることを保証するために例外を引き起こす可能性のあるイベントをシミュレートするにはどうすればよいですか？たとえば、ネットワークの問題、データベースの問題などをシミュレートできるようなテストベッドのようなアプリケーションを実行できますか？例外はその性質上、再現するのが難しいように思われるため、コードで確実に対処できるようにすることは困難です。 私は主にC＃/。NET / Visual Studioを使用して開発していますが、他の言語に関連する回答やリソースが役立つ場合があります。

14 c#  testing  exceptions 

私は常に、プロパティ（つまり、設定/取得操作）が高速/即時であり、障害が発生しないことを念頭に置いてきました。プロパティを取得または設定することを試みる/キャッチする必要はありません。 しかし、いくつかのオブジェクトのプロパティにロールベースのセキュリティを適用するいくつかの方法を検討しています。たとえば、Employee.Salaryプロパティ。他の人が試したいくつかのソリューション（特に1つはここのAOPの例です）は、アクセサに適切な権限がない場合に例外をスローすることを伴います-しかし、これは私が持っていた個人的なルールに反します今長い間。 だから私は尋ねる：私は間違っていますか？状況は変わりましたか？プロパティが例外をスローできることは受け入れられていますか？

14 .net  exceptions 

値の検証を扱うクラスがたくさんあります。たとえば、RangeValidatorクラスは値が指定された範囲内にあるかどうかをチェックします。 すべてのバリデータクラスには2つのメソッドが含まれます：値is_valid(value)を返すTrueかFalse、値に応じて、ensure_valid(value)指定された値をチェックし、値が有効な場合は何もしないか、値が事前定義されたルールに一致しない場合は特定の例外をスローします。 現在、このメソッドに関連する2つの単体テストがあります。 無効な値を渡し、例外がスローされたことを確認するもの。 def test_outside_range(self): with self.assertRaises(demo.ValidationException): demo.RangeValidator(0, 100).ensure_valid(-5) 有効な値を渡すもの。 def test_in_range(self): demo.RangeValidator(0, 100).ensure_valid(25) 2番目のテストは、例外をスローすると失敗し、ensure_valid何もスローしないと成功しますが、assert内部にs がないという事実は奇妙に見えます。そのようなコードを読んだ人は、何もしていないように見えるテストがなぜあるのかをすぐに自問するでしょう。 これは、値を返さず、副作用のないメソッドをテストするときの現在のプラクティスですか？または、テストを別の方法で書き直す必要がありますか？または、単に私がやっていることを説明するコメントを入れますか？

13 unit-testing  exceptions  readability 

例外処理とログ記録の両方の懸念は、どちらも横断的な関心事であるという点で、ほとんど違いは見られません。どう思いますか？メソッドが実装しているコアロジックとインターリーブするのではなく、単独で個別に処理すべきではありませんか？ 編集：私が言いたいことは、私の意見では、メソッドの実装には実行の成功パスのロジックのみを含める必要があり、例外は他の場所で処理する必要があるということです。これは、チェック済み/未チェックの例外に関するものではありません。 たとえば、言語は次のような構造を使用して、完全にチェックされた方法で例外を処理します。 class FileReader { public String readFile(String path) { // implement the reading logic, avoid exception handling } } handler FileReader { handle String readFile(String path) { when (IOException joe) { // somehow access the FileInputStram and close it } } } 上記の概念言語では、クラスのreadFileが例外をスローしていないため、FileReader handlerがない場合、プログラムはコンパイルされません。そのため、ハンドラーを宣言することで、コンパイラーはハンドラーが処理され、プログラムがコンパイルされることを確認できます。FileReader FileReader このようにして、チェック済みおよび未チェックの例外問題の両方の長所、つまり堅牢性と可読性が得られます。

13 design  exceptions  aspect-oriented 

前書き ウェブサイトまたはシステムでエラーが発生した場合は、ログに記録し、エラーの参照コードを含む丁寧なメッセージをユーザーに表示することはもちろん役立ちます。 また、システムがたくさんある場合は、この情報を点在させたくはありません-単一の集中化された場所を用意しておくとよいでしょう。 最も単純なレベルでは、必要なのは、増分IDとエラーの詳細のシリアル化されたダンプだけです。（そして、おそらく「集中化された場所」は電子メールの受信トレイです。） スペクトルのもう一方の端には、おそらく完全に正規化されたデータベースがあり、ボタンを押して1日あたりのエラーのグラフを表示したり、システムXで最も一般的なタイプのエラーを特定したりできます。サーバーBよりも接続エラーなど。 ここで言及しているのは、リモートシステムによるコードレベルのエラー/例外のログです。Jira、Tracなどで行われるような「人間ベース」の問題追跡ではありません。 ご質問 このタイプのシステムを使用した開発者から、特に次の点についての考えを探しています。 欠かせない基本的な機能は何ですか？ 本当に時間を節約する機能があると便利ですか？ どの機能が良いアイデアに思えるかもしれませんが、実際にはそれほど便利ではありませんか？ たとえば、エラーの複数の発生を識別する「重複の表示」機能（「重要でない」詳細が異なることを心配せずに）は非常に重要です。 [このエラーに対して[Jira / etc]で問題を作成する]ボタンは、時間の節約になります。 繰り返しになりますが、私が望んでいるのは、そのようなシステムを使用した人々からの実践的な経験であり、できれば機能が素晴らしい/ひどい理由を裏付けています。 （とにかく理論化するつもりなら、少なくともそのようなものとしてあなたの答えをマークしてください。）

13 exceptions  issue-tracking  errors  logging 

例外処理コードの記述をいつ開始しますか？いつログ文を書き始めますか。 この質問を詳しく説明するために、log4netロギングを備えた.NETプラットフォームを使用していると仮定しますが、一般的な方法で自由に回答してください。 解決策：Windowsフォームプロジェクト。プロジェクト：UI、BusinessRules、DataHandlers だから、作成、読み取り、更新、削除などのデータ操作を最初に行うDataHandlersを書くことに取り掛かりますか？ 次に、ビジネスルールでフォローアップします そして、UIまたは上記の他の組み合わせ。 アプリケーションの機能をテストします。 そして、例外処理コードの作成を開始し、最後にロギングコードを作成しますか？ 例外処理コードの記述を開始する適切なタイミングはいつですか？ PS：本Clean Codeの中で、彼らは最初にtry-catch-finallyブロックを書くと言っています。それで、この質問をすることになりました。

13 programming-practices  exceptions  logging 

次のように表すことができるコードがあります： public class ItemService { public void DeleteItems(IEnumerable<Item> items) { // Save us from possible NullReferenceException below. if(items == null) return; foreach(var item in items) { // For the purpose of this example, lets say I have to iterate over them. // Go to database and delete them. } } …

12 c#  exceptions  error-handling 

まず、C ++に「最終的に」コンストラクトがない理由をよく知っていますか？しかし、別の質問に関する長期にわたるコメントの議論は、別の質問を正当化するようです。 それを除けば問題から、finallyC＃やJavaで基本的に一度だけ存在することができます（== 1）の範囲および単一のスコープあたりが（== n）を複数持つことができますC ++デストラクタ、私は、彼らは基本的に同じものだと思います。（技術的な違いがいくつかあります。） しかし、別のユーザーは次のように主張しました： ...私は、dtorは本質的に（リリースセマティクス）のツールであり、最終的には本質的に（コミットセマンティクス）のツールであると言っていました。理由がわからない場合は、finallyブロックで例外を互いの上にスローするのが正当である理由と、デストラクタが例外でない理由を検討してください。（ある意味、それはデータとコントロールの関係です。デストラクタはデータを解放するためのものであり、最終的にはコントロールを解放するためのものです。それらは異なります。C++がそれらを結び付けるのは残念です。） 誰かがこれを解決できますか？

12 c++  exceptions  finally 

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

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

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

12 programming-practices  books  exceptions  exception-handling 

特定の種類の例外をスローすることをドキュメントに記載するインターフェイスメソッドがあります。そのメソッドの実装は、例外をスローするものを使用します。内部例外がキャッチされ、インターフェイスコントラクトによって宣言された例外がスローされます。ここに、よりよく説明するための小さなコード例を示します。これはPHPで書かれていますが、簡単に理解できます。 // in the interface /** * @return This method returns a doohickey to use when you need to foo * @throws DoohickeyDisasterException */ public function getThatDoohickey(); // in the implementation public function getThatDoohickey() { try { $SomethingInTheClass->doSomethingThatThrowsAnException(); } catch (Exception $Exc) { throw new DoohickeyDisasterException('Message about doohickey failure'); } …

12 exceptions  abstraction