FileMakerスクリプトの「エラー捕捉」と「中止許可」で迷わないために
FileMakerでスクリプトを組んでいると、「エラー捕捉を有効」にするか、「中止を許可」するか、あるいは両方使うべきかで迷うことはないでしょうか。何となくオン・オフしていると、思わぬところでエラーが隠れてしまったり、ユーザーが勝手に処理を止めてしまったりと、トラブルの原因になります。
この記事では、専門用語をできるだけ避けながら、「エラー捕捉」と「中止を許可」の考え方と使い分けのポイントを整理します。日常的な業務スクリプトを作成する方が、最低限おさえておきたいルールをイメージしやすく解説します。
そもそも「エラー捕捉」と「中止を許可」とは？
まず、FileMakerスクリプトでよく使うこの2つのオプションを、ざっくりと役割だけ押さえましょう。
- エラー捕捉（エラーキャプチャ）：FileMakerが通常表示するエラーダイアログを「出さないようにする」設定
- 中止を許可：スクリプト実行中に、ユーザーが「Escキー」やメニューから処理を「止められるかどうか」を決める設定
どちらも「ユーザーにどこまで自由を与えるか」「システム側でどこまで制御するか」に関わるものです。使い方を間違えると、ユーザーには何が起きているか分からないのに、裏では処理だけが進んでしまう、といった状況を招きます。
「エラー捕捉」を使う目的と注意点
エラー捕捉は、主に次のような目的で使います。
- FileMaker標準の無機質なエラーメッセージではなく、自分で用意した分かりやすいメッセージを出したい
- 発生しうるエラーを想定しておき、スクリプト内で条件分岐して対処したい
- ユーザーには見せたくない内部処理（テスト用・管理用）のときに、いちいちエラーを出さずに処理したい
ただし、エラー捕捉を有効にして何も対処をしないと、エラーが「こっそり」発生しているのにユーザーも作成者も気付かない、という状況になりかねません。基本的には次のような流れで使うのがおすすめです。
- スクリプトの先頭で「エラー捕捉を有効：オン」にする
- ポイントとなる場面で「直前のエラー」を確認する（
Get ( LastError )を使うイメージ） - エラーがあったときは、メッセージ表示やロールバック（元に戻す処理）などを行う
- スクリプトの最後か必要なタイミングで、「エラー捕捉を有効：オフ」に戻す
特に2と3が重要で、「エラーを隠す」のではなく、「エラーの扱い方を自分で決める」のがエラー捕捉の本来の使い方です。
「中止を許可」はユーザーとの約束事
「中止を許可」は、スクリプト実行中にユーザーが処理を途中で止められるかどうかを決めます。これも、場面によって適切な設定が異なります。
- 中止を許可：オンに向く場面
- 検索結果の一覧を表示するだけ、印刷プレビューを開くだけなど、途中で止めてもデータが壊れない処理
- 時間がかかるレポート作成など、ユーザーが「やっぱりやめたい」と考える可能性が高い処理
- 中止を許可：オフにすべき場面
- 請求書番号の採番や、在庫の増減処理など、途中で止まると不整合が起きそうな処理
- 複数テーブルにまたがって更新する、削除するなど、途中中断が致命傷になりうる処理
「中止を許可」をオフにした場合は、何らかの理由でスクリプトが固まったように見えると、ユーザーは不安になります。そのため、進行状況を示すダイアログやプログレスバーを表示したり、「数十秒かかります」などの案内を表示したりしておくと安心です。
エラー捕捉と中止許可の基本的な使い分けルール
両方をどう組み合わせるかについて、迷ったときの目安をいくつか挙げます。
- 重要な更新処理
- エラー捕捉：オン（自前でエラー処理）
- 中止を許可：オフ（途中で止めさせない）
- → エラーが出たらロールバックや警告を行い、安全に処理を終わらせる
- 単なる表示・印刷・エクスポートなどの参照系処理
- エラー捕捉：オンまたはオフ（標準メッセージでも許容できるかで判断）
- 中止を許可：オン（ユーザーが中断できるようにする）
- 試験的なスクリプトや開発中の処理
- エラー捕捉：オフのままにして、開発中はあえてエラーを見える化しておく
- 完成してから、必要な箇所にだけエラー捕捉を入れる
ポイントは、「ユーザーに任せてよい範囲」と「システムが責任を持って完了させる範囲」を分けて考えることです。
よくある失敗例と対策
現場でありがちな失敗パターンと、簡単な対策を挙げておきます。
- 失敗例1：エラー捕捉をオンにしただけで、後の処理を書いていない
- → 対策：エラー捕捉をオンにしたら、最低限「エラー発生時のメッセージ表示」だけでも入れておく
- 失敗例2：すべてのスクリプトで「中止を許可：オフ」にしてしまう
- → 対策：ユーザーの操作性も考え、表示系・集計系の処理は中止を許可し、データに影響する処理だけ厳しく管理する
- 失敗例3：長時間処理なのに中止させず、進捗も見せていない
- → 対策：「何件中何件処理中」といったメッセージを出す、または進捗バーを表示して不安を減らす
運用を楽にするためのちょっとした工夫
最後に、日々の運用を少し楽にする考え方を紹介します。
- 共通のエラー処理スクリプトを作る
- どのスクリプトでも使える「エラー発生時の共通処理」（ログ記録、メッセージ表示など）を作っておき、必要なときにサブスクリプトとして呼び出すと管理が楽になります。
- テスト環境ではエラー捕捉をオフにしておく
- テスト段階では、あえてエラーを隠さず、どこでどんなエラーが出ているかを確認しやすくしておきましょう。
- 重要スクリプトには簡単なコメントを残す
- 「なぜ中止を許可していないのか」「なぜここでエラー捕捉をオンにしているのか」をコメントに書き残しておくと、後から見返したときの理解がずっと楽になります。
エラー捕捉と中止許可は、どちらも「ユーザー体験」と「データの安全性」に関わる大事な設定です。全体のバランスを意識しながら、処理の性質に合わせて使い分けることで、使いやすくて安心できるFileMakerシステムに近づけるはずです。