• ベストアンサー

エラー処理について。

Accessマクロで、VBAに変換する際、「エラー処理コードを追加する。」に チェックを入れると出来る「エラー処理コード」についての質問です。 (1)このエラー処理コードは、プログラムの「異常終了」を防ぐと書いてありましたが、そもそもこの異常終了とはどのようなことを言ってるのでしょうか? (例えば、Accessが何の断りもなく、強制終了するなどといったことでしょうか。) 実際にマクロ(テーブルを開く)で作成されたエラーコードの部分だけを動かしてみて、どんなことになるのか試したいのですが、どうすれば試せるのですか? Function マクロ3() On Error GoTo マクロ3_Err DoCmd.OpenTable "テーブル1", acNormal, acEdit マクロ3_Exit: Exit Function マクロ3_Err: MsgBox Error$ Resume マクロ3_Exit End Function (2)そもそもエラー処理は、Access VBA開発ではかなり重要な要素なのでしょうか? 例えば、テキストボックスに何も入力されてなかったら、「入力してください。」とメッセージボックスを表示させるマクロを作るようなことは、 エラー処理とはまた違うのものなのですか?

質問者が選んだベストアンサー

  • ベストアンサー
  • Te-Sho
  • ベストアンサー率52% (247/472)
回答No.2

(1)実際にコードの中で予期せぬことが起こった場合、エラー処理に飛ばすことになります。実際に呼び出すべきテーブルがなかったとか、キーの重複エラーが起こったとかの場合です。MDBで実際コードを書いている場合は、そのエラー部分のコード部分が表示されますが、コンパイルしたMDEを実行しているときや、Accessランタイム上で実行する場合はエラーに対して処理を記述しておかないとその時点で異常終了となり、Accessが強制終了します。 例で行けば DoCmd.OpenTable "テーブル1", acNormal, acEdit でテーブル1が無いだけでもエラーは起こります。 もしテーブル1が必ず存在し、実行時には発生する可能性が無い部分に関してはエラー処理は必要ないですね。テーブル作成クエリで該当テーブルを作る処理があり、その工程前にそのテーブルを参照してしまうようなオペレーションが発生してしまうようならエラー処理は必要です。 (2)エラー処理はどのプログラムを構築するにも必要な物ですね。 ご質問者さまがおっしゃる入力チェックもエラー処理の一つです。ただシステム上で発生する予測できないエラーに対しても異常終了させないで、対応が取れているコードの方がオペレーションを行う人にとって優しい設計となります。 発生要素が違うだけです。 あと、アドバイスですがどんなプログラムでも入力値などに対してエラーを何でも拾って出力するプログラムよりも、コンボボックスやリストボックスを使って入力値を選択や初期値を設定、入力規則で間違った入力をさせない等、事前にエラーを発生させないような設計の方が最近のプログラムでは重要です。もちろんその上でエラー処理はわかりやすく全ての発生条件に対応している方が好ましいです。

その他の回答 (1)

noname#140971
noname#140971
回答No.1

Q、どうすれば試せるのですか? A、以下の要領で。 多分、通常の環境では試せないと思います。 VBエディタで、[ツール]-[オプション]-[全般]-[エラートラップ]で ロエラー処理対象外のエラーで中断 にレ点を付ければ試せます。 その上で、対象テーブル名をリネームして実行します。 「オブジェクト'テーブル1'を見つけることが出来ませんでした。」 というメッセージが表示されます。 ただし、私は、この手のエラー処理は、全て、次のやり方で統一しています。 そして、この場合は、Sub を用います。 Sub マクロ3()   On Error Resume Next   DoCmd.OpenTable "テーブル1", acNormal, acEdit End Sub 10年に一度起こるか否かのエラー。 しかも、テーブルクラッシュが現実に起これば、もっと広範囲に深刻なエラーが出るという判断。 Q、そもそもエラー処理は、Access VBA開発ではかなり重要な要素なのでしょうか? A、極めて重要です。 私は、エラーないし告知を、(1)深刻なエラー、(2)単純なエラー、(3)警告レベルの3つに分けています。 (4)通常のメッセージの表示を加えると4タイプです。 (5)表示後に2、3秒経過すると自動的に閉じるメッセージを加えると5タイプです。 このように、タイプに応じて表示スタイルを統一し一貫性を持たせることはかなり重要です。 ユーザは、エラーの表示様式を見ただけで、どう解決すべきかを簡単に判断できるからです。 StopMsg "深刻なシステム障害を関知しましたので一切の処理を中断します" ErrorMsg "入力した値時にエラーが発生しました。エラーの種類=XXXXX。" Warning "処理不能のデータが見つかりましたので処理をスキップします" Message "[担当者コード]を入力して下さい。" PauseMsg "2件のレコードを削除しました。", 2 いずれも、Access ではなく UNIX版のデータベースソフトで提供されている各種メッセージ関数です。 長い歴史を持つUNIX で、このようにメッセージの表示様式を変えているのは上述の理由からでしょう。 Access でもかかる作法を取り入れることは賢いやり方だと思います。 適切なエラーのアナウンスは、問題解決の最良の手段ですから・・・。