C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[9]: 例外時に「Exception」でCatchしなくていい理由

(過去ログ 139 を表示中)

[トピック内 13 記事 (1 - 13 表示)]　 << 0 >>

■81578 / inTopicNo.1)

　例外時に「Exception」でCatchしなくていい理由

▼■

□投稿者/ ほうじちゃ (1回)-(2016/10/17(Mon) 20:16:18)

分類:[.NET 全般]　

例外の初歩なのかもしれませんが、皆様のご意見をお聞かせください。
以下のような簡単なファイル読み込み処理があった場合に、想定されるエラーはIOExceptionだと思います。
よって、Exceptionで例外を拾う必要はないと上司に注意を受けました。
想定しているExceptionが明示的に拾えているならExceptionで拾う必要はないからという事ですが、この考えは100％あっていますか？
ありえませんが、例えば変数に値を入れる際にメモリ不足で落ちる（いい例が思いつきませんでした・・・。）など本当に想定していないエラーが発生する可能性もあるんじゃないかなと思っていますので
Exceptionはあってもいいと思っているんですが、どうなんでしょうか？

-------------------
Try
　（ファイルの読み込み処理）
Catch ex As System.IO.FileNotFoundException
　（例外処理：「ファイル読み込みに失敗しました」などのMSG）
Catch ex As System.Exception
　（例外処理：「例外エラーが発生しました」などのMSG）
End Try
-------------------

よろしくお願いいたします。

引用返信 編集キー/

■81581 / inTopicNo.2)

　Re[1]: 例外時に「Exception」でCatchしなくていい理由

▲▼■

□投稿者/ WebSurfer (1047回)-(2016/10/17(Mon) 21:23:10)

■No81578 (ほうじちゃさん) に返信

あなたが想定してない例外をキャッチして、あなたは何をできるのですか？

もしその Exception が、マルウエアとかが何か良からぬことをしようとして
いた結果として発生していたら、Exception をキャッチしてそれをなかった
ことにしてしまったらどうなるのでしょう？

素直にそこで終了してしまえば被害はなかったものが、あなたが例外を握り
つぶしてしまったことによって、ライフラインが止まるとか、情報漏えいに
つまがるとか、重大な問題になるかもしれませんよ。

引用返信 編集キー/

■81584 / inTopicNo.3)

　Re[1]: 例外時に「Exception」でCatchしなくていい理由

▲▼■

□投稿者/ WebSurfer (1048回)-(2016/10/17(Mon) 21:42:15)

■No81578 (ほうじちゃさん) に返信

よく読んでみれば上司にそう言われたそうですが、なんで上司に聞かないんですか？

上司に聞いて、その答を書いていただきたいですね。

引用返信 編集キー/

■81586 / inTopicNo.4)

　Re[2]: 例外時に「Exception」でCatchしなくていい理由

▲▼■

□投稿者/ ほうじちゃ (3回)-(2016/10/17(Mon) 21:55:57)

回答ありがとうございます。

> あなたが想定してない例外をキャッチして、あなたは何をできるのですか？
ここではファイルIOを例えに出していましたが、DB処理であればロールバック処理を行う必要があるとおもっています。
ですが、WebSurferさんはマルウェアなどを考慮して記載しない方がいいという意見なんですね。

> よく読んでみれば上司にそう言われたそうですが、なんで上司に聞かないんですか？
>
> 上司に聞いて、その答を書いていただきたいですね。
「想定しているExceptionが明示的に拾えているならExceptionで拾う必要はないからという事です」と回答がありました。
その時はそういうもんなのかなと思いましたが、今になって疑問に思えてきて質問しました。

引き続き皆様のご意見お待ちしています。

引用返信 編集キー/

■81587 / inTopicNo.5)

　Re[3]: 例外時に「Exception」でCatchしなくていい理由

▲▼■

□投稿者/ WebSurfer (1050回)-(2016/10/17(Mon) 22:05:10)

■No81586 (ほうじちゃさん) に返信

> ここではファイルIOを例えに出していましたが、DB処理であればロールバック処理を行う必要があるとおもっています。

ならばロールバックできるようにコードを書けば良い訳で、Exception をキャッチする
必要は 1 ミリもないと思うのですが？

引用返信 編集キー/

■81589 / inTopicNo.6)

　Re[3]: 例外時に「Exception」でCatchしなくていい理由

▲▼■

□投稿者/ WebSurfer (1051回)-(2016/10/17(Mon) 22:14:43)

■No81586 (ほうじちゃさん) に返信

【追加情報】

ロールバックについては Part 2 の「Close() メソッドにより未コミット状態のトラン
ザクションがロールバックされます」というところに注目。

.NETの例外処理 Part.1
https://blogs.msdn.microsoft.com/nakama/2008/12/29/net-part-1/

.NETの例外処理 Part.2
https://blogs.msdn.microsoft.com/nakama/2009/01/02/net-part-2/

.NET 4 からは破損状態例外は catch できなくなっているそうですが、「それでも
Catch (Exception e) を使用するのはよくない」ということについては以下の記事
を見てください。

破損状態例外を処理する
https://msdn.microsoft.com/ja-jp/magazine/dd419661.aspx

引用返信 編集キー/

■81590 / inTopicNo.7)

　Re[3]: 例外時に「Exception」でCatchしなくていい理由

▲▼■

□投稿者/ もりお (25回)-(2016/10/17(Mon) 22:18:32)

■No81586 (ほうじちゃさん) に返信

例外を捕まえる目的しだいな気がします。
お魚さんみたいに捕まえたやったーと捕まえることが目的じゃないので。

DBの例でいいますとロールバックするという目的があって例外を捕まえるわけですよね。

ユーザが入力を間違えたときに例外が発生するという時には
ユーザに再入力をさせるという目的のために例外を捕まえることになります。

DBのロールバックのようにリソースを管理するときにはtry catchで大きく囲って
汎用的な例外を捕まえる。例外の原因がユーザの入力によるものなどはtry catchで
小さく囲って具体的な例外のみを捕まえるって感じですね、私は。

私も他の人がどういうやり方をしているのか興味があります。

引用返信 編集キー/

■81591 / inTopicNo.8)

　Re[4]: 例外時に「Exception」でCatchしなくていい理由

▲▼■

□投稿者/ なちゃ (145回)-(2016/10/18(Tue) 01:26:32)

マルウェアが原因で例外が起きるならIOExceptionになりそうでどっちにしてもスルーしそう。
アプリは終わったところですでにマルウェアは悪さをした後だし、あんまり例えとしてはピンとこない気がする…

引用返信 編集キー/

■81592 / inTopicNo.9)

　Re[5]: 例外時に「Exception」でCatchしなくていい理由

▲▼■

□投稿者/ ビール呑み (1回)-(2016/10/18(Tue) 07:21:12)

上司さんの真意がその一文からだけではわからないので何とも言えませんが、
「あらかじめ想定できる問題については正しい対処法をつけておくべき」
という考えには賛成です。

ただ、「想定できない問題」が起きた際にどうすべきか、については
判断が分かれるところではないでしょうか。
その場合、Exceptionでひとくくりに処理してしまうより他に
手はないのではないかなあ。

ひょっとすると、想定できない問題が出た場合には例外処理せずに
実行時エラーとすべき、という方針なのかもしれませんね。

引用返信 編集キー/

■81593 / inTopicNo.10)

　Re[6]: 例外時に「Exception」でCatchしなくていい理由

▲▼■

□投稿者/ ビール呑み (2回)-(2016/10/18(Tue) 07:54:09)

追加
とはいえ、発生しうる例外なんてほとんど決まっているし、
（質問内容だと「想定されるエラーはIOException」でしたね）
さればこそ「ここで例外処理をしておかねば」という判断にも
至るわけで、
「必要な個別の例外処理をしておけば、汎用的なExceptionの記述は不要」
という意図なのでしょうね。

引用返信 編集キー/

■81594 / inTopicNo.11)

　Re[7]: 例外時に「Exception」でCatchしなくていい理由

▲▼■

□投稿者/ たーん (1回)-(2016/10/18(Tue) 08:26:24)

.NETの例外処理については、結局ここを読んどけば間違いないです。
https://blogs.msdn.microsoft.com/nakama/2008/12/29/net-part-1/

引用返信 編集キー/

■81597 / inTopicNo.12)

　Re[8]: 例外時に「Exception」でCatchしなくていい理由

▲▼■

□投稿者/ furu (75回)-(2016/10/18(Tue) 12:37:28)

Exceptionで例外を拾うかどうかは
使う状況（お客さんとこ?　社内? Web?），
例外の起きる頻度，
デバッグのしやすさ，
例外処理が好きか嫌いかなどなど
いろいろな条件で決まると思います。

ロールバックは途中のロールバックも多いので
私は、finallyで確実にやることにしています。

トランザクション開始();
var isCommit = false;
try
{
  処理1();
  if (止めたい) return;
  処理2();
  コミット();
  isCommit = true;
  処理3();    //通常ここはない
}
finally
{
  if (!isCommit) ロールバック();
}

引用返信 編集キー/

■81598 / inTopicNo.13)

　Re[9]: 例外時に「Exception」でCatchしなくていい理由

▲▼■

□投稿者/ ビール呑み (3回)-(2016/10/18(Tue) 21:51:17)

改めて読み返してみると、質問者さんの意図を全く汲み取っていない回答をしていますね、
自分。反省です。

私が書いたことはほうじちゃさんはすでに承知の上で、「でもそれってどうなの？」
という質問とお見受けしました。

> 想定しているExceptionが明示的に拾えているならExceptionで拾う必要はないからという事ですが、
> この考えは100％あっていますか？

100％かどうかはともかく、あっていると思います。

今回のケースでは、ファイルの読み込み処理にてIOExceptionやらFileNotFoundException
やらを捕捉していますが、これらは「確実に発生する事象」です。
どれだけ慎重に運用したとしても、対象ファイルがみつからなかったり、読み書きに失敗することは
結構な頻度で起こります。だからこそこのタイミングで例外処理をおこなうわけです。

プログラミングに長けた人は「この命令」を実行した際にどういう例外が発生するかを経験的に
わかっていますし、言語仕様にあたれば調べることも可能です。

逆に、ほうじちゃさんが心配している「本当に想定していないエラー」って何でしょうか？
「いい例が思いつかない」ということですから、漠然とした不安でしかないですよね？

メモリが壊れた、とか不正アクセスが、とか想定しないことが起きる可能性はもともと低いうえに、
「この命令を発行したこのタイミングで」起きる可能性はさらに低いでしょう。
ではプログラムの頭からお尻までTry-Catchでくくったとして、その対処は正しいと言えるでしょうか？
何が起きるかわかっていないのに、正しい処置かどうかわかりませんよね。

その一方で、例外処理にはコストが伴います。「たった一文」と思うかもしれませんが、
リソースのコストのみならず、ドキュメント、テスト、メンテナンス等もろもろに
影響してきます（当然金銭面にも）。

たとえ例外処理といえど、明確な目的がないのにむやみやたらに記述を増やすべきではない、
という考えには合理性があると思います。

（個人的には、Exceptionを一行書いておきたい気持ちはわかりますけどね！）

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -