Top > プログラミング > .NET Tips> エラー処理(例外処理)の基本

エラー処理(例外処理)の基本」への評価、コメント

評価

良い / 悪い = 69 / 1 (「良い」の割合 = 0.986 , 人気度 = 1.819

評価する

コメント一覧


通常のコメント
カンチ 2024/05/29 (Wed) 16:55:36
(いつもありがたく参考にさせていただいております)
C#で On Error Resume Next的なことができないかと思いました。
Catch内から Resume Nextするとか
処理1~10があって、それらはエラー起きても次々実行させたいなというとき、一つづつtryで囲むのは避けたいと(面倒とも言う)
そういうのはふさわしくないと思われる方もいるでしょうが

評価の理由
匿名 2023/07/26 (Wed) 12:50:07
評価:良い
とても解り易かったです。

評価の理由
匿名 2022/11/30 (Wed) 10:54:11
評価:良い
すごくわかりやすかったです

通常のコメント
匿名 2014/02/12 (Wed) 02:16:49
補足です。デバッグ中にエラー発生行を知りたいということでしたら以下で対応できます。

1.Visual Studio メニューのデバッグ、例外を選択。
2.Common Language Runtime Exceptions のスローされるときにチェックを入れ、OKを押下。

こうすると Try~Catchが書かれていてもエラー発生行で止まるようになります。そのままだとデバッグしづらくなるので、終わったら設定を元に戻してください。

通常のコメント
匿名 2014/02/11 (Tue) 23:51:10
> Catchしたとき、エラーの発生した行は取得できるのでしょうか?

exe と同一ディレクトリに pdb があれば ex.StackTrace でファイル名と行番号が取れます。行番号はエラーの発生した次の行を指します。

pdb はClickOnce等のインストーラーで既定で配布対象外になっていますが、設定を変更すれば配布できます。但し、pdb は機密情報(ソースの情報)を含み、サイズも大きいので配布するかどうかは慎重に検討してください。

エラー情報をログに記録する目的であれば ex.ToString がお勧めです。型、内容、スタックトレース、内部例外を全て文字列に変換してくれます。UnhandledException と組み合わせてデータベース等にログを記録するようにすれば、利用現場で起こっているエラーを容易に追跡・対処できるようになります。

通常のコメント
ふるふる 2013/12/5 (Thu) 10:01:02
Catchしたとき、エラーの発生した行は取得できるのでしょうか?
できるならその方法が知りたいです。
VB6 のときは、Resumeでエラー発生行がわかりましたけど。

評価の理由
名無しさん 2012/03/17 (Sat) 22:35:10
評価:良い
やったところ、OvewflowException、InvalidCastExceptionにも対応しているらしいです。

評価の理由
匿名 2012/01/29 (Sun) 16:55:09
評価:良い
よーわかった。

評価の理由
mu 2010/11/20 (Sat) 12:53:51
評価:良い
大変参考になりました。

通常のコメント
monnta 2010/10/20 (Wed) 10:09:04
投げかける(thrw)ですね。失礼しました。

通常のコメント
monnta 2010/10/20 (Wed) 09:26:16
いつも大変お世話になっています。
説明文中「スロー(slow)」は「スルー(through)」ではないのでしょうか。

通常のコメント
管理人 2010/09/5 (Sun) 23:18:05
> 途中までは素晴らしいのだが、「できるだけ例外が発生しないようにする」以降のサンプルは頂けない。
> 何行も Try ~ Catch で囲むと、後で変更があった場合に修正漏れの原因となる。

簡単に言うと、「File.Existsをtryブロックに入れるな」ということでしょうか?実は私もそう思っていました(以前はこの記事のコードもそうなっていました)。ところが、説明にも書きましたが、MSDNの

File.Exists メソッド (System.IO)
http://msdn.microsoft.com/ja-jp/library/system.io.file.exists(VS.80).aspx

には、「Exists メソッドとファイルに対して実行する操作を try...catch ブロック内にラップすることをお勧めします。」と明言されています。MSDNのこの記述を無視することはできませんので、File.Existsをtryブロック内に入れました。

ところが先ほど確認したところ、.NET Framework 4.0からこの記述がきれいに消えていました。どういうことなのかまだ分かりませんが、もし以前の記述が間違い(あるいは無意味)であったならば、私の記事も書き換えたいと思います。

> 再スロー、キャッチしなかったものが呼び出し元に戻り、最終的には関連の「捕捉されなかった例外がスローされたことを知る」につながる事を説明して頂きたい。

この点、説明不足であれば補強します。ただしこの点も、以前は「捕捉されなかった例外がスローされたことを知る」の説明を本文に入れていたものを、あえてやめました。というのは、あまりに安易にこの方法を使われる方が多いと感じたからです。初心者の方には安易にこの方法を使ってほしくありませんので、あえて「関連」にだけ入れることにしました。

引き続きご意見がございましたら、よろしくお願いいたします。

通常のコメント
お名前 2010/09/5 (Sun) 14:51:01
途中までは素晴らしいのだが、「できるだけ例外が発生しないようにする」以降のサンプルは頂けない。
何行も Try ~ Catch で囲むと、後で変更があった場合に修正漏れの原因となる。
また、VB6から移って来た人がこのサンプルを見たら、ON ERROR GOTO の代わりとして使って、すべての Function・Sub プロシージャが Try ~ Catch で溢れかえったあげく、どこかでトラップミスを発生させることになるだろう。(実際にorz)
再スロー、キャッチしなかったものが呼び出し元に戻り、最終的には関連の「捕捉されなかった例外がスローされたことを知る」につながる事を説明して頂きたい。

評価の理由
匿名 2010/09/3 (Fri) 10:05:03
評価:良い
大変勉強になりました。

評価の理由
匿名 2010/03/8 (Mon) 21:07:12
評価:良い
詳しい説明、大変参考になりました。

通常のコメント
匿名 2009/12/4 (Fri) 17:37:32
非常に助かりました

評価の理由
ToC 2009/11/13 (Fri) 13:30:11
評価:良い
説明が丁寧でわかりやすかったです。

評価の理由
2008/09/28 (Sun) 13:03:53
評価:良い
いろんなパターンが紹介されてて
よかったです

コメントの投稿

[説明]