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

例外を設計するとき、ユーザーまたは開発者が理解する必要があるメッセージを作成する必要がありますか？実際に例外メッセージの読者はだれですか？ 例外メッセージはまったく役に立たないと思うし、いつも書くのに苦労しています。慣例により、例外のタイプは既に何かが機能しなかった理由と、カスタムプロパティがファイル名、インデックス、キーなどの情報をさらに追加する理由を既に示しているはずです。自動生成されたメッセージでも実行でき、含まれる必要があるのは、追加のプロパティのリストを含む例外の名前だけです。これは、手書きのテキストとまったく同じように便利です。 メッセージをまったく書き込まずに、コードでハードコーディングするのではなく、おそらく異なる言語で意味のあるメッセージを作成する特別な例外レンダラーを用意する方が良いと思いませんか？ これらの質問のいずれかが私の質問に対する答えを提供するかどうか尋ねられました： 適切な例外メッセージを書く方法 多くの例外メッセージに有用な詳細が含まれていないのはなぜですか？ 私は両方を読みましたが、彼らの答えに満足していませんでした。彼らは一般的にユーザーについて話し、宛先ではなくメッセージ自体の内容に焦点を当て、エンドユーザーと開発者の少なくとも2人が存在することがわかりました。例外メッセージを書くとき、私はどちらに話すべきかわかりません。 有名なメッセージは、例外タイプの名前を異なる単語で繰り返しているだけなので、実際の価値はまったくないと思います。完全に自動生成できます。 私にとって例外メッセージは、読者の差別化に欠けています。完璧なエンドユーザー用と開発者のための1：例外は、メッセージの少なくとも2つのバージョンを提供する必要があります。単なるメッセージと呼ぶのは一般的すぎます。その後、開発者のメッセージは英語で記述する必要がありますが、エンドユーザーのメッセージは他の言語に翻訳する必要がある場合があります。このすべてを1つのメッセージだけで実現することは不可能であるため、例外は、先ほど述べたように、さまざまな言語で利用できるエンドユーザーメッセージに識別子を提供する必要があります。 リンクされている他のすべての質問を読むと、例外メッセージは実際には開発者ではなくエンドユーザーが読むことを意図しているという印象を受けます... 1つのメッセージはケーキを食べて食べるようなものです。

27 design  exceptions 

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 

失敗時に例外がスローされるか、nullが返されるかを制御する追加のブール型パラメーターを持つメソッド/関数によく遭遇します。 どちらの場合がより良い選択であるかについてはすでに議論がありますので、ここではこれに焦点を合わせません。たとえば、マジック値を返す、例外をスローする、失敗した場合にfalseを返すなどを参照してください。 代わりに、両方の方法をサポートしたい理由があると仮定しましょう。 個人的には、そのようなメソッドはむしろ2つに分割する必要があると思います。1つは失敗時に例外をスローし、もう1つは失敗時にnullを返します。 それで、どちらが良いですか？ A：$exception_on_failureパラメータ付きの1つのメソッド。 /** * @param int $id * @param bool $exception_on_failure * * @return Item|null * The item, or null if not found and $exception_on_failure is false. * @throws NoSuchItemException * Thrown if item not found, and $exception_on_failure is true. */ function loadItem(int $id, bool $exception_on_failure): …

24 exceptions 

Perl、Python、C ++、またはTclプログラムが未処理の例外で停止するたびに、これらの言語ランタイムはプロセスにゼロ以外の終了コードを登録するように注意します。Eclipseベースのプログラムでさえ、起動中に失敗すると1を返します。java.exeしかし、標準で実行されるプログラムは、プログラムがSystem.exit()終了値で呼び出されない限り、どんなに突然終了しても喜んでゼロを返します。でもAssertionFailedErrorまたはがUnsatisfiedLinkError成功して終了として呼び出し元のプログラムに戻って報告されています。 もちろん、すべてのシステムにプログラムのリターンコードがあるわけではありませんが、UnixとWindowsはjava.lang.Process.exitValue()、子プロセスを保証するのに十分なほど重要でした。親プロセスの規約を順守することも保証されませんか？ これは言語設計の欠陥ですか、それとも実装の欠陥ですか？それは良いアイデアだという議論はありますか？

24 java  exceptions 

Scalaなどの一部のプログラミング言語には、値を含む場合と含まない場合があるOption型（とも呼ばれるMaybe）の概念があります。 それらについて私が読んだことから、彼らは広くこの問題に対処するより優れた方法であると考えられていますnull。なぜなら、ランタイム中に単に爆発するのではなく、値がない場合を考慮するようにプログラマーに明示的に強制するためです。 一方、Javaでチェックされた例外は悪い考えと見なされるようで、Javaはそれらを実装する唯一の広く使用されている言語のようです。しかし、その背後にある考え方Optionは、例外がスローされる可能性があるという事実にプログラマーに明示的に対処させるために、型にいくらか似ているようです。 Option型にないチェック済み例外には、いくつかの追加の問題がありますか？または、これらのアイデアは私が思うほど似ていないのか、例外ではなくオプションの明示的な処理を強制する正当な理由がありますか？

23 exceptions 

ファイルをアップロードする関数であるAPIを作成しています。ファイルが正しくアップロードされた場合、この関数は何も/ voidを返さず、何らかの問題が発生したときに例外をスローします。 なぜ偽りではなく例外なのか？例外の内部で、失敗の理由（接続なし、ファイル名の欠落、パスワードの誤り、ファイルの説明の欠落など）を指定できるためです。カスタム例外を作成したかった（APIユーザーがすべてのエラーを処理するのに役立つ列挙型を使用）。 これは良い習慣ですか、それともオブジェクトを返す方が良いですか（内部にブール値、オプションのエラーメッセージ、エラーの列挙を含む）？

22 java  api-design  exceptions  functions  architectural-patterns 

例外と例外処理はどこから来たのですか？ .NETの使用方法、C ++のサポート方法が気に入っています（ただし、ライブラリは残念ながら戻りコードを使用するか、代わりにCで作成されています）。私はすべての新しい言語でその標準を知っていますが、誰が最初に設計したのですか、それはどこから来たのですか？ C ++はそれを使用する最初の言語ですか？他に古いものは知りません。

22 history  exceptions 

例外に関する Eric Lippertの記事を読むことは、プロデューサーとしてもコンシューマとしても、例外にどのように取り組むべきかについて、間違いなく目を見張るものでした。ただし、厄介な例外のスローを回避する方法に関するガイドラインを定義するのにまだ苦労しています。 具体的には： a）他の誰かがあなたの前にレコードを変更したか、b）作成しようとしている値が既に存在するため、失敗する可能性のあるSaveメソッドがあるとします。これらの条件は例外ではなく予期されるものであるため、例外をスローする代わりに、メソッドのTryバージョン、TrySaveを作成することにします。TrySaveは、保存が成功したかどうかを示すブール値を返します。しかし、それが失敗した場合、消費者はどのように問題があったのかを知ることができますか？または、結果を示す列挙型、Ok / RecordAlreadyModified / ValueAlreadyExistsなどを返すのが最善でしょうか？integer.TryParseでは、メソッドが失敗する理由は1つしかないため、この問題は存在しません。 前の例は本当に厄介な状況ですか？または、この場合に例外をスローするのが好ましい方法でしょうか？Entityフレームワークを含むほとんどのライブラリとフレームワークでそれがどのように行われるかを知っています。 メソッドのTryバージョンを作成するタイミングと、メソッドが機能するかどうかを事前にテストする方法を提供するタイミングをどのように決定しますか？私は現在これらのガイドラインに従っています： 競合状態の可能性がある場合は、Tryバージョンを作成します。これにより、消費者が外因性の例外をキャッチする必要がなくなります。たとえば、前に説明したSaveメソッド。 条件をテストするメソッドが元のメソッドが行うことをほぼすべて実行する場合は、Tryバージョンを作成します。たとえば、integer.TryParse（）。 それ以外の場合は、条件をテストするメソッドを作成します。

21 exceptions 

一部のプログラミング言語の人々によるヌル参照の一貫したバッシングについては、よくわかりません。それらの何がそんなに悪いのですか？存在しないファイルへの読み取りアクセスを要求した場合、例外またはnull参照を取得できてうれしく思いますが、例外は良好と見なされますが、null参照は不良と見なされます。この背後にある理由は何ですか？

21 programming-languages  exceptions  null 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 例外処理をプログラマーに教える方法を教えてください。他のすべてのこと-データ構造、ASP.NET、WinForms、WPF、WCF-を簡単に教えられます。名前を付ければ、すべてが簡単に教えられます。 例外処理では、try-catch-finallyを教えることは、例外処理の構文的な性質にすぎません。 ただし、教えるべきことは-コードのどの部分をtryブロックに入れますか？catchブロックで何をしますか？ 例で説明しましょう。 Windows Formsプロジェクト（小さなユーティリティ）で作業しており、3つの異なるプロジェクトで以下のように設計しました。 UILayer BusinessLayer DataLayer DataLayerで例外（XDocumentをロードすると例外がスローされると言います）が発生した場合（UILayerがBusinessLayerを呼び出し、BusinessLayerがDataLayerを呼び出します）、次のようにしますか？ //In DataLayer try { XDocument xd_XmlDocument = XDocument.Load("systems.xml"); } catch(Exception ex) { throw ex; } BusinessLayerで再びスローされ、ログファイルに書き込むUILayerでキャッチされるのはどれですか？ これはあなたが例外処理をどのように行っているのですか？

21 java  programming-practices  c#  teaching  exceptions 

catchブロックは、ロジックの記述、つまりフロー制御などの処理に使用する必要がありますか？または、例外をスローするためだけに？コードの効率や保守性に影響しますか？ catchブロックにロジックを記述した場合の副作用（ある場合）は何ですか？ 編集： catchブロック内にロジックを記述したJava SDKクラスを見てきました。例（java.lang.Integerクラスから抜粋したスニペット）： try { result = Integer.valueOf(nm.substring(index), radix); result = negative ? new Integer(-result.intValue()) : result; } catch (NumberFormatException e) { String constant = negative ? new String("-" + nm.substring(index)) : nm.substring(index); result = Integer.valueOf(constant, radix); } EDIT2： 私は、例外の中に例外的なケースのロジックを書くことの利点としてそれを数えるチュートリアルを行っていました： 例外を使用すると、コードのメインフローを記述し、例外的なケースに対処することができます。 catchブロックでロジックを作成する場合としない場合の具体的なガイドラインはありますか？

21 java  programming-practices  exceptions 

設定 例外をいつどのように使用するかを判断するのに苦労することがよくあります。簡単な例を考えてみましょう。AbeVigodaがまだ生きているかどうかを判断するために、「http://www.abevigoda.com/」と言うWebページをスクレイピングしているとします。これを行うには、ページをダウンロードし、「Abe Vigoda」というフレーズが表示される時間を探すだけです。安倍のステータスが含まれているため、最初の外観を返します。概念的には、次のようになります。 def get_abe_status(url): # download the page page = download_page(url) # get all mentions of Abe Vigoda hits = page.find_all_mentions("Abe Vigoda") # parse the first hit for his status status = parse_abe_status(hits[0]) # he's either alive or dead return status == "alive" where parse_abe_status(s)は「Abe Vigoda is something」という形式の文字列を取り、「something」部分を返します。 このページを安倍のステータスのためにスクレイピングするはるかに優れた、より堅牢な方法があることを議論する前に、これは私がいる一般的な状況を強調するために使用される単純で不自然な例であることを忘れないでください。 …

20 python  exceptions 

私はいつも、ソフトウェアのさまざまな部分にいくつの異なる例外クラスを実装してスローすべきかと考えていました。私の特定の開発は通常C ++ / C＃/ Java関連ですが、これはすべての言語の問題だと思います。 スローする例外の良い数と、開発者コミュニティが良いライブラリに期待するものを理解したいと思います。 私が見るトレードオフには以下が含まれます： より多くの例外クラスにより、APIユーザーの非常に細かいレベルのエラー処理が可能になります（ユーザー構成やデータエラー、またはファイルが見つからない） 例外クラスを追加すると、単なる文字列メッセージやエラーコードではなく、エラー固有の情報を例外に埋め込むことができます 例外クラスが増えると、コードのメンテナンスが増えます 例外クラスが増えると、APIがユーザーに近づきにくくなる可能性があります 例外の使用法を理解したいシナリオは次のとおりです。 ファイルのロードやパラメーターの設定を含む「構成」段階 ライブラリがタスクを実行し、おそらく別のスレッドで何らかの作業を行う「操作」タイプのフェーズ中 例外を使用しない、またはより少ない例外を（比較として）使用しないエラー報告の他のパタ​​ーンには、次のものがあります。 例外は少ないが、ルックアップとして使用できるエラーコードを埋め込む エラーコードとフラグを関数から直接返す（スレッドからは不可能な場合がある） エラー時にイベントまたはコールバックシステムを実装（スタックの巻き戻しを回避） 開発者として、あなたは何を見たいですか？ 多数の例外がある場合、とにかくそれらを個別に処理するエラーを気にしますか？ 操作の段階に応じて、エラー処理タイプを優先しますか？

20 design-patterns  exceptions 

私はしばらく前に書いたコードをレビューしていましたが、メソッドのパラメーターに問題がある場合にargumentnullexceptionsおよび/またはargumentexceptionsをスローするプライベートメソッドがいくつかあることがわかります。 私の理論的根拠は、誰かが将来メソッドを「誤用」しようとする場合、アプリケーションの将来の証明に役立つと思います。ただし、それがプライベートメソッドであり、このメソッドを呼び出す可能性のある人々が関連するコメントとコードを見ることができる場合、これをスローする必要はありません。混乱させることはありますが、確かにそれらを使用しても害はありません。 私の考えでは、これらの例外は、一般に公開されるAPIのようなものでは一般的により有用であると考えています。

20 exceptions 

例外に関する追加情報を提供する必要があるたびに、実際にこれを行う正しい方法はどれかと思います。 この質問のために、例を作成しました。Abbreviationプロパティを更新するクラスがあると仮定しましょう。SOLIDの観点からは完全ではないかもしれませんが、DIを介してワーカーメソッドをいくつかのサービスで渡しても同じ状況が発生します-コンテキストが存在しないという例外が発生します。例に戻る... class Person { public int Id { get; set; } public string Name { get; set; } public string Abbreviation { get; set; } } 次に、クラスのインスタンスと、worker-methodが呼び出されるループがあります。それは投げることができStringTooShortExceptionます。 var persons = { new Person { Id = 1, Name = "Fo" }, new Person { Id = 2, Name = …

20 c#  exceptions