投稿2023/02/22 00:37
NETでクラスを作成しています。
メソッドでチェック処理を行い、問題があった際は、メッセージボックスを表示しようと考えています。
以下のどちらの方法が一般的でしょうか？
・メソッド内でメッセージボックスを表示する。
・メソッド内ではメッセージボックスは表示せずに、エラーコードを返して、呼び出し元でメッセージボックスを表示する。
ご回答のほど、宜しくお願いします。
回答2件
0
質問のコメントに対する返事がないので、あなたの言う「問題」は以下の (a) で、
(a) 予測可能で正しい業務フローに戻すことができる業務エラー（例：ユーザーの入力間違い）
(b) 予測できないもしくは予測はできても何の対応もできない例外（例：DB サーバーダウン）
正しい業務フローに戻すためのユーザーにメッセージ表示するのに「メッセージボックス」が適切というケースと勝手に想像して回答しておきます。想像が違ったらどこがどう違うのか書いてください。
以下のどちらの方法が一般的でしょうか？
・メソッド内でメッセージボックスを表示する。
・メソッド内ではメッセージボックスは表示せずに、エラーコードを返して、呼び出し元でメッセージボックスを表示する。
そこは、アプリ全体で考えてどこでどういうタイミングで表示するのが適切かとか、クラスの仕様書があればそれに従うとか、組織のコーディングルールによる、とかいう話になると思います。
そのあたりが分からない第三者（Teratail の回答者）が、どちらが良いとかとか、どちらが一般的かとか言えないはずです。
ご参考までに、上記 (a), (b) 両方を考えての .NET アプリのでの例外処理について、Microsoft Blog に書いてあったことを要約して以下に紹介しておきます（Blog は今はリンク切れです）。
(1) 上記 (a)「業務エラー」と (b)「例外」を区別して対処する。
(2) 「例外」はランタイムに拾わせてアプリケーションを停止させる。無かったことにして、ユーザが作業を続けられるようにすると、強制的に停止させるより好ましからざる状況に陥るかも（ユーザーが大事なデータを壊したりとか）。
(3) よほどのことがない限り try-catch は書かない。
(4) キャッチせざるを得ない場合でも Execption はキャッチしない。範囲を絞る。例えば DB 関係の例外が予測されるなら SqlException に限定して catch し、Number プロパティなどでエラーの内容を調べて対処するとか。
(5) 間違って補足してしまった例外は throw する。（注：catch ブロックでキャッチした例外を throw するとスタックトレースが途切れるので単に throw と書く）
(6) ユーザーへの通知が必要なら、集約的例外処置を利用する。
「業務エラー」についてはユーザー入力の間違いが原因ということが多いと思いますが、フレームワークにユーザー入力の検証機能が備わっている場合は、メッセージボックスとかは使わないで、フレームワークの機能を利用するというのが良さそうです。
投稿2023/02/22 04:27
退会済みユーザー
総合スコア0
0
ベストアンサー
そのクラスが何者なのか次第…かな，と．
そいつがGUIの一部なのであればそこでメッセージボックスを出しても良いだろうけど，
そうじゃない（内側の/純粋な処理実装の）存在であるなら，そいつが「メッセージボックスを出す実装」を持っているのは違う感．
投稿2023/02/22 01:16
総合スコア11658
あなたの回答
tips
プレビュー
Q&A
