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

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

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

Re[2]: エラー処理の手法について

分類:[C#]　

2018/04/27(Fri) 11:57:14 編集(投稿者)

お世話になります。

エラー処理の手法について、基礎的なところもあると思いますが何点か教えて頂きたいです。

①そもそも、どこにエラー処理を仕掛けるべきか
　エラー処理をするにあたり、最初にぶつかっている部分です。
　エラー処理はすべき。でも、どこでエラーが出るか分からないため
　現状ではメソッドの内容全てを try の中に入れてしまっています。
　良くない実装というのは感じているのですが、ではどこで発生するのかが判断できません。
　皆さんはどのように判断されているのでしょうか。

②個別に try を仕掛けるとして、スコープの問題
　まさにこのサイトに書いてあるような問題に悩まされています。
　http://d.hatena.ne.jp/yaneurao/20100929

　個別に try を仕掛けるとスコープが各tryで区切られてしまい、とてもプログラムが書きづらいです。
　何か解決方法があるでしょうか。

③エラーの区分けはどのようにすればいいでしょうか
　一口にエラーと言っても、色々なものがあると思います。
　例えば
　　・ユーザがルール外の入力をした、開こうとしたファイルがなかった　などの、その場で操作をやり直して欲しいエラー
　　・同じIDでログインしている人がいてログインができない　などの、そのユーザにはどうしようもないけどリトライできるエラー
　　・プログラム中で発生した致命的エラー　その場でソフトを落とすのが最善なエラー

　それぞれのエラーで、発生した時にどのように処理するかが変わってくることがあると思います。
　catch する際に Exception の種類で分ければいいのか、と最初は思っていたのですが
　例えば、NullReferenceException が発生した時に、それは致命的エラーでソフトを落とすべきなのか、それともやり直してもらうべきなのか？
　そもそも、どのような処理でどのようなエラーが起きる可能性があるのかも分からない状態です。
　全てのエラーに備えることなどできるのでしょうか？

よろしくお願いします。

■No87213 (MTK さん) に返信

以下に紹介する記事に書いてありますが「よほどのことがない限り、アプリケーションで
try-catch を書いてはいけません」が基本だと思います。

そう考えれば ①、② の件には悩む必要はないと思います。

例外処置について、自分的に一般的と思っていることは以下の通りです。③ に対する答えも若干
含まれていると思いますがいかがですか。

(1) 予測可能で正しい業務フローに戻すことができる「業務エラー」（例：ユーザーの入力間違い）
　　と、予測できないもしくは予測はできても何の対応もできない「例外」（例：DB サーバーダウ
　　ン）を区別して対処。

(2) 「例外」はランタイムに拾わせてアプリケーションを停止させる。

(3) よほどのことがない限り try-catch は書かない。

(4) キャッチせざるを得ない場合でも Execption はキャッチしない。

(5) 間違って補足してしまった例外は throw する。（注：catch ブロックでキャッチした例外を
　　throw するとスタックトレースが途切れるので単に throw と書く）

(6) ユーザーへの通知が必要なら、集約的例外処置を利用する。

以上期は以下の記事の受け売りです。詳しくはそちらを見てください。

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

＃参考にされているサイトはタイトルだけ見て閉じてしまったので詳しくは見ていません。
　（〇〇とか書いてある記事に限って〇〇のことが多いと思っているので）

エラー処理というか、例外処理ですね(^-^)

エラー処理は、私の場合、大半は変数の値や戻り値で制御します。
例外についても、クラスライブラリが吐いてくる例外をキャッチする
だけで自分で例外を生成することはめったにしません。

自分で例外を生成するとしたら、部品的なクラスを作った時に、
部品内部から「やばいよ、これ！」と突発的に伝えたい時だけかな。

自動車でいったら、
  ・燃料切れが近いよ
みたいなのは例外にはしない。
  ・あ、飛び出してきた人が！！
みたいなのだけを例外にすると思う。

そして、try{}で囲う範囲ですが、
今の例で言えば、「飛び出してくる人」がいそうな場所は全て例外処理
対象で良いんじゃないでしょうか？
ま、公道を走ってる限り、try{}継続でしょうな。

例で解説しちゃったんで、うまく伝わるか心配ですが（笑）

意味のある例外処理をする、これが基本だと思いますよ。

アプリケーション内で致命的なエラーが起きたら、可能な限りエラーの情報を残してアプリケーションを正常なフローで終わらせたいですね(main関数でreturnで終わるイメージ）。
ある一定の単位で遷移するものであれば、元の状態に戻れるのがうれしいかなと。

どうコードを書くというよりも、どういった仕様にするのか、これが決まればその通りに実装すればよいと思います。
それを置きざりにして形式美を唱えたりかくあるべきと主張されても。。。ねーどうしようこの人？って感じに周りから見られるかなって思います。

気を付けておくとすればマルチスレッドの場合と、メッセージループで自分が実装していない箇所で起きる例外の場合、
この２つに注意しておけばWindowsのクライアントアプリだとすれば大丈夫かなって思います。
サーバアプリとかは知らないっと。

■No87214 (WebSurfer さん) に返信

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

try-catch をどう使うかと考えていましたが、そういうものだったんですね。
考え方が180度変わりました。

結構作り上げてしまった後ですが、貼って頂いたリンクを見ながらリファクタリングしてみようと思います。
ありがとうございました。

■No87215 (ぶなっぷさん) に返信

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

エラー処理≠例外処理　なんですね！覚えておきます。

なるほどなるほど、危なそうなところには範囲で仕掛けておくということですね。
例え、なんかしっくり来ます！
想定していない、突発的な例外のみ例外処理するべきだと思います。

ありがとうございました。

2018/04/27(Fri) 17:40:55 編集(投稿者)

■No87216 (にゃるらさん) に返信

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

> 意味のある例外処理をする、これが基本だと思いますよ。
>
> アプリケーション内で致命的なエラーが起きたら、可能な限りエラーの情報を残してアプリケーションを正常なフローで終わらせたいですね(main関数でreturnで終わるイメージ）。
> ある一定の単位で遷移するものであれば、元の状態に戻れるのがうれしいかなと。

仰る通りです。
私もそのように処理されるのが理想です！

> どうコードを書くというよりも、どういった仕様にするのか、これが決まればその通りに実装すればよいと思います。
> それを置きざりにして形式美を唱えたりかくあるべきと主張されても。。。ねーどうしようこの人？って感じに周りから見られるかなって思います。

確かに・・・。
まずはフローチャートを書いてみようと思います。
ありがとうございました。

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

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

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

Re[2]: エラー処理の手法について

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