既に軽く考察も入っているが、まとめる意味でも書いてみよう。
実際の活用パターンに当てはめた方が理解しやすいかもしれないので、そうしてみる。
まず、普通は深いところで起きた致命的なエラーはユーザーには通知しない。こういうのは表には「内部エラー」などとして、ログに詳細を書き出しておくべきだろう。
VB6の時に困っていたのは、内部エラーとユーザーに通知するエラーの両方がある場合。
戻り値をStringにして、エラーメッセージを階層的に積み重ねていくという方法の場合、戻り値に何か文字列が入っている=エラーとなるのですが、それが致命的なものか、ユーザーに通知すべてエラーなのかがわからなかったわけです。
まぁ、エラーコードも返せたので、それで区別を付ければいいですが、エラーコードに意味づけを持たせる必要とかが出てきます。
.NETの場合は、引数間違いとか、IOエラーとかいろんな例外クラスがあるので、この例外クラスの時はユーザーに通知して、それ以外は内部エラーとして処理をするといったことが、簡単にできそうです。
しかし、自分が作るメソッドでどの例外が発生して、それはどういうときに発生するかというのはちゃんとXMLコメントに残しておかないといけないでしょうね。
.NET Frameworkのクラス群もいろんな例外を発生させるのですが、同じArgumentExceptionを発生させるクラスでも、それぞれでその例外を発生させる意味合いが違っていて、それがドキュメントに記載されています。
Javaと違ってthorws指示詞?が無いので、例外キャッチを強制はできないので、なおさらコメントは重要でしょうね。
・・・となると、エラーコードに意味もたせるのと、あまり労力が変わらないような気がするのは気のせいか。まぁ、無機質な数値の羅列よりはArgumentExceptionとかの方がわかりやすいという点では確かなのだけれども。
さて、最初にあげたパターンのどれでいくかとかを考えていこうかと思ったけど、焼酎が効いてきて眠くなってきたのでまた今度にする。おやすみ。
