タグ付けされた質問 「try-catch」

try-catchは、コードセクションによって発生した例外をキャッチするための構文構造です

5
コードを高速化してみてください。
try-catchの影響をテストするためにいくつかのコードを書きましたが、驚くべき結果がいくつかありました。 static void Main(string[] args) { Thread.CurrentThread.Priority = ThreadPriority.Highest; Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.RealTime; long start = 0, stop = 0, elapsed = 0; double avg = 0.0; long temp = Fibo(1); for (int i = 1; i < 100000000; i++) { start = Stopwatch.GetTimestamp(); temp = Fibo(100); stop = Stopwatch.GetTimestamp(); elapsed …

10
同じcatch句で複数のJava例外をキャッチできますか?
Javaでは、私はこのようなことをしたいです: try { ... } catch (/* code to catch IllegalArgumentException, SecurityException, IllegalAccessException, and NoSuchFieldException at the same time */) { someCode(); } ...の代わりに: try { ... } catch (IllegalArgumentException e) { someCode(); } catch (SecurityException e) { someCode(); } catch (IllegalAccessException e) { someCode(); } catch (NoSuchFieldException e) { …

17
C#で例外をキャッチして再スローする理由
記事C#-シリアル化可能なDTO上のデータ転送オブジェクトを見ています。 記事には次のコードが含まれています。 public static string SerializeDTO(DTO dto) { try { XmlSerializer xmlSer = new XmlSerializer(dto.GetType()); StringWriter sWriter = new StringWriter(); xmlSer.Serialize(sWriter, dto); return sWriter.ToString(); } catch(Exception ex) { throw ex; } } 記事の残りの部分は正気で妥当なように見えますが(noobにとって)、そのtry-catch-throwはWtfExceptionをスローします... これは、例外をまったく処理しないこととまったく同じではありませんか? エルゴ: public static string SerializeDTO(DTO dto) { XmlSerializer xmlSer = new XmlSerializer(dto.GetType()); StringWriter sWriter = new …

10
Pythonでtry-except-elseを使用することは良い習慣ですか?
Pythonでは時々、次のようなブロックが表示されます。 try: try_this(whatever) except SomeException as exception: #Handle exception else: return something try-except-elseが存在する理由は何ですか? フロー制御を実行するために例外を使用しているので、そのようなプログラミングは好きではありません。でも、もしそれが言語に含まれているなら、それには正当な理由があるに違いないですね。 例外はエラーではなく、例外的な状況でのみ使用する必要があることを理解しています(例:ファイルをディスクに書き込もうとして、空き領域がない、または権限がない可能性があります)。フローではないコントロール。 通常、私は例外を次のように処理します: something = some_default_value try: something = try_this(whatever) except SomeException as exception: #Handle exception finally: return something または、例外が発生しても何も返さない場合は、次のようにします。 try: something = try_this(whatever) return something except SomeException as exception: #Handle exception

16
すべてのブロックを「try」-「catch」でラップしない方がよいのはなぜですか?
メソッドが例外をスローする可能性がある場合、意味のあるtryブロックでこの呼び出しを保護しないのは無謀だと私は常に信じてきました。 私は投稿したばかりです ' try、catchブロックをスローする可能性のある呼び出しは常にラップする必要があります。「この質問に対して、それは「著しく悪いアドバイス」であると言われました-理由を理解したいと思います。

11
警告を試す/キャッチすることはできますか?
一部のphpネイティブ関数からスローされる警告をキャッチして処理する必要があります。 具体的には: array dns_get_record ( string $hostname [, int $type= DNS_ANY [, array &$authns [, array &$addtl ]]] ) DNSクエリが失敗すると、警告がスローされます。 try/catchは警告が例外ではないため機能しません。 私には2つのオプションがあります: set_error_handler 私はそれを使用してページ内のすべての警告をフィルタリングする必要があるため、やり過ぎのように見えます(これは本当ですか?)。 エラー報告/表示を調整して、これらの警告が画面にエコーされないようにしてから、戻り値を確認してください。の場合false、ホスト名のレコードは見つかりません。 ここでのベストプラクティスは何ですか?

5
Rでtrycatchを書く方法
trycatchウェブからのダウンロードのエラーに対処するためのコードを書きたいのですが。 url <- c( "http://stat.ethz.ch/R-manual/R-devel/library/base/html/connections.html", "http://en.wikipedia.org/wiki/Xz") y <- mapply(readLines, con=url) これらの2つのステートメントは正常に実行されます。以下に、存在しないWebアドレスを作成します。 url <- c("xxxxx", "http://en.wikipedia.org/wiki/Xz") url[1]存在しません。どのようにしてtrycatchループ(関数)を 作成するのですか? URLが間違っている場合、出力は「Web URLが間違っている、取得できません」となります。 URLが間違っている場合、コードは停止しませんが、URLリストの最後までダウンロードを続けますか?

16
なぜ「except:pass」が不適切なプログラミング手法なのですか?
の使用except: passが推奨されない方法に関する他のスタックオーバーフローの質問に対するコメントをよく見ます。なぜこれが悪いのですか?時々私はただエラーが何であるか気にしないで、コードを続けたいだけです。 try: something except: pass なぜexcept: passブロックの使用が悪いのですか?何が悪いのですか?それは私ということであるpassエラーオンまたはIそのexceptいずれかのエラー?

11
例外がスローされない場合、try / catchブロックはパフォーマンスを低下させますか?
マイクロソフトの従業員とのコードレビュー中に、try{}ブロック内のコードの大きなセクションに遭遇しました。彼女とIT担当者は、これがコードのパフォーマンスに影響を与える可能性があることを示唆しました。実際、彼らはほとんどのコードはtry / catchブロックの外にあるべきであり、重要なセクションだけがチェックされるべきであると提案しました。マイクロソフト社の従業員は、次のホワイトペーパーを追加して、不正なtry / catchブロックに対して警告を発すると述べています。 調べてみたところ、最適化に影響する可能性があることがわかりましたが、スコープ間で変数が共有されている場合にのみ適用されるようです。 私はコードの保守性について質問したり、適切な例外を処理したりすることもしていません(問題のコードは間違いなくリファクタリングが必要です)。フロー制御の例外の使用についても言及していません。これはほとんどの場合明らかに間違っています。これらは重要な問題です(いくつかはより重要です)が、ここでは焦点を当てていません。 例外がスローされない場合、try / catchブロックはパフォーマンスにどのように影響しますか?

12
Tryブロックで値を返すと、Finallyステートメントのコードが起動しますか?
私は友人のコードをレビューしていて、彼がtry-finallyブロック内でreturnステートメントを使用していたと言います。最後のセクションのコードは、tryブロックの残りの部分が実行されなくても実行されますか? 例: public bool someMethod() { try { return true; throw new Exception("test"); // doesn't seem to get executed } finally { //code in question } }

25
どのように再試行キャッチを実装しますか?
try-catchは、例外処理を支援することを目的としています。これは、どういうわけか、システムをより堅牢にするのに役立つことを意味します。予期しないイベントからの回復を試みてください。 実行および命令(メッセージの送信)の際に何かが発生する可能性があるため、tryに含まれています。ほぼ予期しないことが発生した場合は、何かを行うことができます。例外をログに記録するためだけに呼び出されたとは思わない。キャッチブロックは、エラーから回復する機会を提供することを目的としています。 ここで、問題点を修正できるため、エラーから回復するとします。再試行するのはとても良いことです: try{ some_instruction(); } catch (NearlyUnexpectedException e){ fix_the_problem(); retry; } これはすぐに永遠のループに入りますが、fix_the_problemがtrueを返したとしたら、再試行します。Javaにはそのようなことはないので、この問題をどのように解決しますか?これを解決するための最良の設計コードは何ですか? これは哲学的な質問のようなものです。私が求めていることがJavaで直接サポートされていないことがすでにわかっているからです。

15
例外処理にtry catchを使用することがベストプラクティスです。
上級開発者であると主張する誰かからの私の同僚のコードを維持しながら、私はしばしば次のコードを見る: try { //do something } catch { //Do nothing } または時々彼らは次のtry catchブロックのようなログファイルにログ情報を書き込みます try { //do some work } catch(Exception exception) { WriteException2LogFile(exception); } 彼らがやったことがベストプラクティスなのかと思っているだけです。私の考えでは、ユーザーがシステムで何が起こるかを知っている必要があるので、それは私を混乱させます。 アドバイスをください。

20
なぜ{…}やっと{…}が良いのでしょうか。{…}キャッチ{}してみませんか?
引数なしでキャッチを使用することは、特にそのキャッチが何もしない場合は、悪い形だと人々が言うのを見てきました。 StreamReader reader=new StreamReader("myfile.txt"); try { int i = 5 / 0; } catch // No args, so it will catch any exception {} reader.Close(); ただし、これは適切な形式と見なされます。 StreamReader reader=new StreamReader("myfile.txt"); try { int i = 5 / 0; } finally // Will execute despite any exception { reader.Close(); } 私が知る限りでは、クリーンアップコードをfinallyブロックに配置することと、try..catchブロックの後にクリーンアップコードを配置することの唯一の違いは、tryブロックにreturnステートメントがある場合です(その場合、finallyのクリーンアップコードは実行されますが、try..catchの後のコードは実行されません)。 そうでなければ、最後に何がそれほど特別なのですか?

20
空のキャッチブロックが悪い考えであるのはなぜですか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 この質問を改善する 私はtry-catchに関する質問を見たことがあります。(Jon Skeetを含め)空のcatchブロックは本当に悪い考えだと言っていますか?なんでこれ?空のキャッチが間違った設計決定ではない状況はありませんか? たとえば、どこかから追加の情報(Webサービス、データベース)を取得したい場合があり、この情報を取得してもしなくてもかまいません。だからあなたはそれを取得しようとし、何かが起こっても大丈夫です、私は単に「キャッチ(例外は無視されました){}」を追加し、それですべてです

7
例外がスローされない場合でも、try-catchブロックを使用するとコストがかかりますか?
例外をキャッチするのはコストがかかることはわかっています。しかし、例外がスローされない場合でも、Javaでtry-catchブロックを使用するのもコストがかかりますか? Stack Overflowの質問/回答を見つけました。なぜ、tryブロックが高価なのですか?しかし、それは.NET用です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.