Excel VBA > VBA:実務活用 > エラートラップ自体が持つ罠!?
このエントリーをはてなブックマークに追加

エラートラップ自体が持つ罠!?

エラートラップを使うときとは?

VBAでシステム・ツール等を開発し、それを第3者に使ってもらうときに、エラーが頻発すると「バグだらけ」となり、信頼を落としかねません。
なので、バグがあったとしても、その中で極力「ソフトランディング」するためにエラートラップを使うことがよくあります。
通常の開発レベルになると使用するモジュールやプロシージャの数はかなりの量になることも少なくないです。(ちなみに昔はステップ(コード)数が多いとそれだけで自己満足していましたが、現在は、より少ないコードで機能を実装できる方がはるかにすごいと思っています)
エラートラップを使うことで、たとえエラーが発生した場合でも、例の「実行時エラーが発生しました」の画面は利用者に見せないで、どちらかというと「このエラーはシステムとしてはエラーだけど、想定内だよ」的な形で表すことができます。

エラートラップはエラーの原因を突き止めるのが困難になる?

ただし、なんでもかんでもエラートラップをすれば良いわけではないと考えています。むしろ可能(お客さんが怒らない?)ならば、エラートラップしないで提供したいくらいと個人的には思ってしまいます。
もちろん、これには理由があります。
VBAのエラートラップには通常、「Resume Next」と「Goto XX」があります。
使い方次第ではどちらも危険ですが、簡単にいえば、どちらも「実行時エラーの内容が隠蔽されてしまい、解決に時間がかかってしまう」です。

ここでは「Goto XX」で説明します。

Sub 親()

    On Error GoTo ErrHandler

    ‘サブプロシージャ2つをコール
    Call 子供1
    Call 子供2

    MsgBox “終了”

    Exit Sub

‘エラー発生時に表示し、処理を終了
ErrHandler:
    MsgBox “処理中に予期せぬエラーが発生しましたので処理を中止します”, vbCritical

End Sub

上記はプロシージャ「親」から子供1、子供2プロシージャをコールしています。
そして親プロシージャの先頭でエラートラップしています。この場合、エラーが発生すると「ErrHandler」に勝手に制御が飛んでいき、メッセージを表示して処理が終了されます。

既にお気づきの方もいるかもしれませんが、これ自体でエラー内容が隠蔽されているわけです。
例えば、利用者から「予期せぬエラーでメッセージが出て終了したけど・・」と言われても、解決できる情報が少なすぎますね。

むしろこれだったら「実行時エラーが出て、『インデックスが有効範囲にありません。』と出たよ」と言われた方が解決できる情報に近づくわけです。

できればデバッグボタン押して黄色でハイライトされたコードも知れるとかなり助かりますが(笑)。

ただし、もちろんエラーの傾向などが類推できれば、Select Case(やIF)とErr.Numberを併用して、より本来のエラー原因に近いメッセージを出すことは可能です。しかしそれだったら、初めから関連するだろう部分をもっと深く広くテストして、エラー自体を潰してしまった方がスマートにも思えます。この辺は好みだけでなく、会社としてのコーディング規則もあるので一概には言えないですが。。

いずれにしても、このようにエラートラップをすることで解決が困難になることもあります。かといって、実行時エラーばかり見せるわけにもいかないのが、辛いところです。
従い、処理が正しく行われているかどうかをバックグランドで押さえておくためにエラーログ(機能)も同時に入れるなどした工夫が必要になってきます。

カテゴリ:VBA:実務活用