エラーは「避ける」ものではなく「扱う」もの
GASでスクリプトを書いていると、必ずと言っていいほどエラーに遭遇します。
API通信に失敗した、想定外の値が入った、権限が足りなかった──こうした事象は、完全に防ぐことはできません。
重要なのは、エラーをどう扱うかです。
何も対策をしなければ、スクリプトは途中で止まり、原因も分からないままになります。
この記事では、GASにおける try-catch を使った例外処理の基本と、
Logger.logを活用したログ設計について解説します。
GAS009で学んだ「設定値管理」ともつながる、実務向けの考え方がテーマです。
目次
例外処理が必要になる場面
GASでは、次のような処理でエラーが発生しやすくなります。
- スプレッドシートやDriveへのアクセス
- 外部API通信（UrlFetchApp）
- PropertiesServiceの値取得
- 型や値が想定と異なる場合
これらは「いつか必ず失敗する可能性がある処理」です。
そのため、try-catchで囲む前提で設計するのが実務では普通です。
try-catchの基本構文
try-catchは、「失敗するかもしれない処理」を安全に実行するための構文です。
基本形は次のとおりです。
try {
// エラーが起きる可能性のある処理
} catch (e) {
// エラー発生時の処理
}
tryブロック内でエラーが発生すると、処理は中断され、catchブロックに移ります。
このとき、エラー内容は e に格納されます。
catchを書かずに放置すると、GASは即座に停止します。
自動実行（トリガー）では、これが沈黙した失敗につながります。
catchで何をすべきか
catchブロックで重要なのは、「何もしない」ことではありません。
最低限、エラー内容を記録する必要があります。
try {
riskyProcess();
} catch (e) {
Logger.log(e.toString());
}
これだけでも、原因追跡が可能になります。
実務では、次のような情報も一緒に残すと有効です。
- どの処理で失敗したか
- 日時
- 引数や対象ID
catchは「復旧する場所」ではなく、
状況を把握するための分岐点だと考えると分かりやすくなります。
Logger.logとの役割分担
GAS006で学んだ Logger.log は、デバッグ用ログです。
try-catchと組み合わせることで、ログはより意味を持つようになります。
ポイントは、正常系と異常系でログの意味を分けることです。
try {
Logger.log('処理開始');
riskyProcess();
Logger.log('処理完了');
} catch (e) {
Logger.log('エラー発生：' + e.message);
}
このようにしておくと、
「どこまで処理が進んだか」「どこで止まったか」が一目で分かります。
PropertiesServiceと例外処理の連携
GAS009で学んだPropertiesServiceは、例外処理と非常に相性が良い仕組みです。
代表的なのが、「設定値が存在しない場合」の扱いです。
function getApiKeyOrFail() {
const key = PropertiesService.getScriptProperties()
.getProperty('API_KEY');
if (!key) {
throw new Error('API_KEYが未設定です');
}
return key;
}
このように、意図的にエラーを投げることで、
try-catch側に制御を渡すことができます。
例外処理は「受け身」だけでなく、
設計上のガードとしても使える点が重要です。
実務での設計パターン
実務では、try-catchは次のような方針で設計されます。
- 回復できないエラーは止める
- 一時的な失敗はログだけ残す
- 設定ミスは即座に検知する
すべてを握りつぶすのではなく、
止めるべきもの・続けるものを分けることが重要です。
この判断ができるようになると、
GASは「とりあえず動くスクリプト」から「運用できる自動化」へ進化します。
まとめ
この記事では、try-catchを使ったGASの例外処理と、ログ設計の基本を解説しました。
エラーを正しく扱えるようになることで、自動実行や長期運用が現実的になります。
次回からは、第2部として「スプレッドシート操作」に進みます。
ここから先は、GASを本格的な業務ツールとして使っていくフェーズです。
0 件のコメント:
コメントを投稿