ここから本文です

エラー設計について、各関数内でエラーが発生した場合、その関数内からメッセージ...

aho********さん

2013/12/2914:20:11

エラー設計について、各関数内でエラーが発生した場合、その関数内からメッセージを出すか、メイン処理に戻してから出力させるようにすべきかいつも迷います。
皆さんはどんなポリシーでエラー

出力の設計をしますか?

閲覧数:
373
回答数:
5

違反報告

ベストアンサーに選ばれた回答

tar********さん

2013/12/2914:54:33

同感です。

私は次のように処理しています。

※プログラムのバグによるエラー → 即座に関数内でログに書き込む
※オペレータの操作・条件設定ミス → OKボタンがクリックされた時
※測定値の異常 → 即座に関数内でログに書き込む
※異常の通知 → 一連の処理が終わった時点(つまりメイン側)でメッセージ表示やメール送信などで通知

私の場合は常にオペレータがその場に居ない1日~月単位での自動処理が多いのでメッセージは出さずステータス表示のみとしログに書き込んでおいて動きは止めずに処理は続行させるパターンが殆どです。

質問した人からのコメント

2014/1/5 18:02:09

ベストアンサー決められません。

ベストアンサー以外の回答

1〜4件/4件中

並び替え:回答日時の
新しい順
|古い順

kei********さん

2014/1/313:17:48

そのままでは処理を終われない(途中でやめるわけにはいかない)ような場合は関数内でメッセージを出しますが、基本的にはエラーコードを戻り値にして処理を終了します。

C言語において関数は「式」の一部に過ぎないのですから、関数内で余計なことをすべきではない(=副作用は少ないほうがいい)と思っています。

qwe********さん

2013/12/3120:40:30

出力の設計をしますか?
==>設計というキーワードが出てきたので、業務システムだとして回答します。
単なる入力エラーに対するメッセージですと、その関数内です。
処理を続行出来ないような重大なエラーですと、エラー処理を行う関数に飛ばして処理させます。

b_f********さん

2013/12/2916:45:53

例えば、そのサブルーチンをほかのシステムに流用するような場合を考えれば、エラーメッセージはコーラー側に任せた方が良いことになります。
必ずしも、エラーメッセージが出力されてよいシステムばかりではないですし、そもそもGUIプログラムとか常駐プログラムとかだと、標準出力にエラー出しても意味がないというのもありますしね。

というわけで、そのサブルーチンがどのレベルのロジックなのかで判断するのが適切ですね。

MVCの概念で考れば、エラーについても表示はビューに任せるのが適切なので、そのサブルーチンがビューに該当するものでないなら…ってことになるでしょう。

ちなみに、C++であれば、例外を使うことで、直近のtry catcheまで一気に飛びますから、そういった方法を使うのが効率的です。

uoy********さん

編集あり2014/1/322:46:47

エラーフラグをboolやintで返すようにして
呼び出し元で
エラーフラグが立ってるかどうか判断して
エラーじゃなきゃ次へいき
エラーならエラー処理してます。
因みに.netです。

ログの吐き方はプロジェクトによって様々です。
その場で吐いてしまうものもあれば
エラーメッセージやエラーコードを返して一番上の方でそれを受け取りログを出す、なんていうのもあります。

みんなで作る知恵袋 悩みや疑問、なんでも気軽にきいちゃおう!

Q&Aをキーワードで検索:

Yahoo! JAPANは、回答に記載された内容の信ぴょう性、正確性を保証しておりません。
お客様自身の責任と判断で、ご利用ください。
本文はここまでです このページの先頭へ

「追加する」ボタンを押してください。

閉じる

※知恵コレクションに追加された質問は選択されたID/ニックネームのMy知恵袋で確認できます。

不適切な投稿でないことを報告しました。

閉じる