エラートラップ自体が持つ罠！？

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

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

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

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

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

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

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

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

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

シート内にある全セルの文字数を取得する(ループ未使用版)
「Range,Cells」と「Resize」のセル範囲指定を比べてみる
動的なコントロールの「Enter」、「Exit」を疑似的に検知する
できるだけファイルをコピーされたくない時の対策について考える
Listboxに10列以上を追加するとき
Like演算子(「○○が含まれない」検索)で気を付けること
ListBoxに長い文字列を設定するとき
Excelで作ったツール・システムをできるだけ外部から管理する方法はあるか？
「RowSourceプロパティを設定できません。プロパティの値が無効です。」エラーについて
DictionaryでKey(キー)やItem(アイテム)をループして取得する方法3種類