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

通常、このパターンは、作業中のすべてのPythonプロジェクトで少なくとも1回は見られます。たとえば、Djangoプロジェクトでは、これは多くの場合、基本設定ファイルの最後に追加されます。 try: from .local_settings import * except ImportError: pass また： try: import simplejson as json except ImportError: import json これはいつも私を少しでも悩ませてきました。モジュールが正常にインポートされた後、ImportErrorそれ自体がトリガーされるとどうなりますか？たとえば、最初の例では、local_settingsモジュールは存在しますが、local_settings存在しないモジュールをインポートしようとします。 これはオプションのモジュールをインポートする最も安全な方法ですか、この機能を実現するためのより良い方法はありますか？それはコンテキスト/使用法に依存しますか（そうであれば、このアプローチをいつ使用するかを決定するガイドラインは何ですか？）

10 python  exceptions 

私は、次のような彼らは、一般的な例外を好む数人の友人とI.間の論争に実行したClientErrorExceptionとServerErrorException私は物事にもっと具体的に作ることを好むのに対し、例外のフィールドとして詳細に。たとえば、次のような例外がいくつかある場合があります。 BadRequestException AuthenticationFailureException ProductNotFoundException これらはそれぞれ、APIから返されたエラーコードに基づいて構築されています。 例外の利点に従うと、これはJavaにとって慣用的なようです。しかし、私の友人の意見は全く珍しいことではありません。 コードの読みやすさとAPIの使いやすさの点で好ましい方法はありますか、それとも本当に好みに帰着するだけですか？

9 java  design  exceptions 

パブリックメソッドの引数を検証することをお勧めします。 彼がnullを期待していない場合、nullをチェックする必要がありますか？ メソッドはパラメータを検証する必要がありますか？ MSDN-CA1062：パブリックメソッドの引数を検証します（.NETの背景がありますが、質問はC＃固有ではありません） 動機は理解できます。モジュールが誤った方法で使用される場合は、予測できない動作ではなく、すぐに例外をスローする必要があります。 気になるのは、モジュールの使用中に発生する可能性のあるエラーは間違った引数だけではないということです。推奨事項に従ってエラーのエスカレーションを望まない場合に、チェックロジックを追加する必要があるいくつかのエラーシナリオを以下に示します。 着信-予期しない引数 着信-モジュールの状態が間違っています 外部呼び出し-予期しない結果が返されました 外部呼び出し-予期しない副作用（呼び出しモジュールへの二重入力、他の依存関係の状態を壊す） 私はこれらすべての条件を考慮して、1つのメソッド（申し訳ありませんが、C＃ではありません）で単純なモジュールを作成しようとしました： public sealed class Room { private readonly IDoorFactory _doorFactory; private bool _entered; private IDoor _door; public Room(IDoorFactory doorFactory) { if (doorFactory == null) throw new ArgumentNullException("doorFactory"); _doorFactory = doorFactory; } public void Open() { if (_door != null) throw …

9 design  code-quality  coding-standards  exceptions  error-handling 

このSOの質問を読むと、ユーザー入力を検証するために例外をスローすることは不快に思われるようです。 しかし、誰がこのデータを検証する必要がありますか？私のアプリケーションでは、すべての検証はビジネスレイヤーで行われます。これは、クラス自体だけが、各プロパティの有効な値を実際に認識しているためです。プロパティを検証するためのルールをコントローラーにコピーすると、検証ルールが変更される可能性があり、変更を行う場所が2つあります。 ビジネス層で検証を行う必要があるという私の前提は間違っていますか？ 私がやること したがって、私のコードは通常、次のようになります。 <?php class Person { private $name; private $age; public function setName($n) { $n = trim($n); if (mb_strlen($n) == 0) { throw new ValidationException("Name cannot be empty"); } $this->name = $n; } public function setAge($a) { if (!is_int($a)) { if (!ctype_digit(trim($a))) { throw new ValidationException("Age $a …

9 language-agnostic  exceptions  validation 

私は現在、例外の使用方法を改善しようとしていますが、プログラミングエラーを示す例外（たとえば、誰かが引数としてnullを渡した、またはオブジェクトが破棄された後にメソッドを呼び出した）と、呼び出し側の障害ではない操作（I / O例外など）。 これらの2種類の例外はどのように異なる方法で処理する必要がありますか？エラー例外を明示的に文書化する必要があると思いますか、または関連する前提条件を文書化するだけで十分ですか？また、明らかな場合（たとえば、ObjectDisposedException破棄されたオブジェクトでメソッドを呼び出す場合）、前提条件またはエラー例外のドキュメントを省略できますか？

9 java  c#  c++  exceptions 

次のコードを検討してください。 if (x == 1) { throw "no good; aborting" ; } [... more code ...] 今、このコードを考えてみましょう： if (x == 1) { throw "no good; aborting" ; } else { [... more code ...] } 2つのケースはまったく同じように機能します。最初のケースには、のコードの残りの部分を「囲む」必要がないという利点がありますelse。2番目の方法には、elsefor every を明示的に持つという慣例に従うという利点がありますif。 誰かが一方を他方に有利に支持するような確かな議論を提供できますか？

9 coding-style  exceptions 

私はこの質問について、例外が発生した場所にできるだけ近いところで例外を処理する方法についてのアドバイスを読んでいます。 ベストプラクティスのジレンマは、try / catch / finallyを使用してenum （または値を表すint、エラーの場合は0、OKの場合は1、警告の場合は2など）を返す必要があるかどうかです。答えは常に正しいですか、それとも呼び出し側がそれを処理するように例外を通過させるべきですか？ 私が集めることができるものから、場合によってはこれが異なるかもしれないので、元のアドバイスは奇妙に思えます。 たとえば、Webサービスでは、常に状態を返す必要があるため、例外はその場で処理する必要がありますが、http経由でデータを投稿/取得する関数内で、例外（たとえば404の場合）は、それを起動したものにパススルーするだけです。そうでない場合は、結果の品質（エラー：404）と結果自体を呼び出し側に通知する方法を作成する必要があります。 データを取得/ポストするヘルパー関数内で404例外をキャッチすることは可能ですが、そうする必要がありますか？smallintを使用してプログラムの状態を示し（もちろん、それらを適切に文書化し）、この情報を外部の健全性検証の目的（すべてok /エラー処理）に使用するのは私だけですか？ 更新：メインの分類で致命的または致命的でない例外を予期していましたが、回答を害しないようにこれを含めたくありませんでした。質問が何であるかを明確にしましょう：例外をスローするのではなく、スローされる例外を処理します。望ましい結果とは：エラーを検出し、エラーからの回復を試みます。復旧できない場合は、最も意味のあるフィードバックを提供してください。 ここでも、http get / postの例での問題は、元の呼び出し元に何が起こったかを説明する新しいオブジェクトを提供する必要があるかということです。このヘルパーが使用しているライブラリにあった場合、操作のステータスコードを提供することを期待しますか、それともtry-catchブロックに含めますか？設計している場合、ステータスコードを提供するか、例外をスローして、代わりに上位レベルにステータスコード/メッセージに変換させますか？ あらすじ：例外を生成するのではなく、コードの一部がステータスコードと、コードが生成する結果を返す場合、どのように選択しましたか？

9 exceptions  error-handling  exception-handling 

例外が本番環境でのみ発生する問題に取り組んでいます。私はこれらの環境にアクセスできず、この例外の意味もわかりません。エラーの説明を見て、原因がわかりません。 javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure 誰かがこの種の問題に取り組む方法について私に助言してくれませんか？

9 exceptions 

malloc0を返すか、新しい例外がスローされた場合はどうしますか？停止するか、OOM状態を生き残るか、ユーザーの作業を保存しようとしますか？

9 programming-practices  exceptions 

COMポートを介して単純なハードウェアデバイスとインターフェイスするクラスを作成しています。デバイスはさまざまなモードを使用するように構成できるため、私のクラスにはタイプSetOperatingModeを取り込む関数があります。次のようになります。enumUsbDeviceMode class UsbDevice { public void SetOperatingMode(UsbDeviceMode mode) { byte[] buffer = new byte[4]; buffer[0] = 0x5A; buffer[1] = 0x02; buffer[2] = (byte)mode; buffer[3] = 0x00; //IO_TYPE is always 0 in this case. _port.Write(buffer, 0, 4); int read = _port.Read(buffer, 0, 2); bool successfulSet = (read == 2 && buffer[0] …

9 c#  exceptions  exception-handling 

私の会社では、自分で設計し、インターフェイスとして指定するサーバーセントラルサービスを含むWebアプリケーションを構築しています。つまり、インターフェイスはアプリケーション固有であり、その後、時間の経過とともに変更される可能性があるサードパーティのライブラリを使用して実装されます。例外に関しては、サービスによってスローされる例外は、実装固有の例外ではなく、独自のアプリケーション固有の例外でなければならないことに気付きました。 さて、私は私たちの例外がどのように構造化され、相互に関連付けられるべきか疑問に思っています。 まず、一般的な例外について考えますMyAppException。この例外は、予期しない問題が発生したことを示しています。ユーザーにメッセージを表示して、問題が発生し、現在作業中であることを伝えることが最善の方法です。エラーは、データベースがクラッシュしたか、何か類似したものである可能性があります。この例外は、データベースを操作するすべてのメソッドからほとんどスローされます。 次に、例外を検討しますMyAppDuplicateException。この例外は、ユーザーがすでに存在するデータベースに何かを保存しようとしたことを示します。ここでは、より具体的なエラーメッセージを表示できます。この例外は、データベース行を挿入または更新するメソッドからのみスローされます。 アプリケーションにはMyAppDuplicateException、その他の予期しないエラー状況と同様のその他の例外を含めることもできます。例MyAppNotFoundExceptionなど... 今私の質問に： 他の例外は拡張する必要がありますMyAppExceptionか？実はその理由はわかりません。色んなところで見ただけで、目的があるのか​​なと思います。私が見るようにこれの欠点は、try / catch-statementがこの場合の特定の例外を気にする必要がないことです。それは単にトップの例外をキャッチすることができ、そのため、特定の例外を持っていることのほとんどのポイントであった特定のエラーを処理する必要はありません。 他の例外がない場合ではない拡張するMyAppException、すべきMyAppExceptionことjava.lang.RuntimeException？これは、コードを実行してそれをキャッチする必要はありません。例外のポイントは、何か不明なことが発生し、実行中のコードがそれを処理できるように期待されていないということだからです。リクエストのエントリポイントのコードには、キャッチMyAppExceptionしてユーザーにメッセージが表示されることを確認するtry / catchステートメントを含めることができます。 編集などの特定の例外をMyAppDuplicateExceptionチェックする必要があるかどうかは問題ではありません。チェックする必要があります。

9 java  exceptions 

Doorが管理しているsがあるとしDoorServiceます。DoorServiceデータベースに格納されているドアを開く閉じてロックを担当しています。 public interface DoorService { void open(Door door) throws DoorLockedException, DoorAlreadyOpenedException; void close(Door door) throws DoorAlreadyClosedException; /** * Closes the door if open */ void lock(Door door) throws DoorAlreadyLockedException; } lockメソッドにはがありDoorAlreadyLockedException、openメソッドにはがありDoorLockedExceptionます。これはオプションですが、他にも可能なオプションがあります。 1）DoorLockedExceptionすべてに使用すると、lock()通話で例外をキャッチするときに少し面倒です try { doorService.lock(myDoor); } catch(DoorLockedException ex) // door ALREADY locked { //error handling... } 2）2つの例外タイプがDoorLockedExceptionあり、DoorAlreadyLockedException 3）2つの例外タイプがありますが、 DoorAlreadyLockedException extends …

8 java  exceptions  class-design 

スローデストラクタを備えた型と、それを値で受け取る関数があるとします。 その操作は、基本的な例外保証よりも優れたものを提供できますか？ または別の方法で定式化すると、操作にコミットアンドロールバックセマンティクスがあるかどうかを判断するときに、値によって渡された引数の破棄を無視できますか？ #include <cstdlib> struct X { ~X() noexcept(0) { if(rand()%6 == 0) throw 0; } // some state }; void update(database db, X arg) noexcept; X x; update(db, x); 個人的には、ウィキペディアの定義に基づく 強力な例外安全性、コミットまたはロールバックセマンティクスとも呼ばれます：操作は失敗する可能性がありますが、失敗した操作には副作用がないことが保証されているため、すべてのデータは元の値を保持します 関数自体がスローすることさえできないとしてもupdate、強く例外セーフであると説明することは有用ではないと私は思います。 私は私の現在の理解の愚かさを私に示してくれる人、あるいはもっと良い議論をしてくれれば幸いです。

8 c++  exceptions  exception-handling  error-handling 

これは一般的なデザインの質問ですが、私がC＃と.NETに焦点を合わせています。これは、これらが現在使用している言語だからです。 独自の新しい例外クラスを作成する必要がありますか、それともわずかに異なる目的で既存のフレームワーク例外を選択する必要がありますか？ たとえば、メンバ（つまり、型など）が予期されていたが、を使用してアセンブリを読み取っているときに見つからなかったことを示す例外が必要であることがわかりましたMono.Cecil。基本クラスライブラリは例外を定義しますMissingMemberException。これは、私が欲しいものを正確に伝えているようですが、説明では次のように述べています。 存在しないクラスメンバーに動的にアクセスしようとした場合にスローされる例外。 メンバーに動的にアクセスするのではなく、アセンブリを受動的に操作するため、これは正確には適合しません。

8 c#  object-oriented  .net  exceptions 

コードを書くとき、私はしばしばこのようなことをしたいです： try: foo() except FooError: handle_foo() else: try: bar() except BarError: handle_bar() else: try: baz() except BazError: handle_baz() else: qux() finally: cleanup() 明らかに、これは完全に判読できません。しかし、それは比較的単純なアイデアを表しています。一連の関数（または短いコードスニペット）を、それぞれに例外ハンドラーを付けて実行し、関数が失敗するとすぐに停止します。Pythonがこのコードに構文糖を提供できると思います。おそらく次のようなものです。 # NB: This is *not* valid Python try: foo() except FooError: handle_foo() # GOTO finally block else try: bar() except BarError: handle_bar() # ditto else try: baz() …

8 python  exceptions