まとめ
大別して
- 200 OK
- エラーステータス(400 500)
- 接続不能(無効なURL)
がある。
異常系のうちステータスコードの異常はオプションでレスポンスか例外扱いかを選べる
タイムアウトは制御方法がなく、例外処理するしかない。
正常系
const res = UrlFetchApp.fetch(URL)
接続先が問題ないなら気にすることはない
ステータスコード異常
try {
const res = UrlFetchApp.fetch(URL)
} catch(e) {}
400や500番台が返されると通常は例外として処理される。
ただ、エラーであることをチェックしたい場合もあるので、そういう場合は
muteHttpExceptionsオプションを使う。
const res = UrlFetchApp.fetch(URL, {muteHttpExceptions:true})
res.getResponseCode() != 200
これで応答が帰ってくるかぎりは例外処理で行わなくてよくなる。
利用できないURL
サーバーが死んでいるときなど応答がないとき、この例外エラーが発生する。
これはmuteHttpExceptionsでは制御できない。例外で対処するほかない。
が、問題はそこではなく、応答待ち時間がめっちゃとられることが問題。
タイムアウトの時間の資料は見つからなかったが、私の手元のトリガー実行時間から、
おおよそいちリクエストを大体50秒近く待機する。
トリガーで自動で働いている限りはどれだけ時間を使ってくれても私は困らないが、問題は無料の利用枠の問題である。
GoogleAppsScriptでよくはまる制約まとめ - バグ取りの日々
GASのトリガーの実行時間は一日合計90分。
たとえば、奇特な例として「普段は接続できないがまれに接続できることをチェックしたい」逆死活監視とでもいうような機能を作る場合、
いち実行に50秒だとおよそ
15分に一度の実行が限界になる。
チェックしたいURLが増えると間隔の限界は減り、
二つのURLをチェックするとそれだけで30分に一度しか実行できなくなる。
そして問題はこのタイムアウトまでの時間を操作できないことで、10秒応答がなかったらタイムアウト、などとは設定できない。
Class UrlFetchApp | Apps Script | Google Developers
同期処理なので途中でabortするようなこともできず、
HTTPのヘッダーで操作できないかと考えた結果は前回のとおり
HTTPのリクエストヘッダーでタイムアウトを操作できない - Qiita
トリガー時間は共用なので他のスクリプトにも影響が出てくる困り者。
死んでいるURLを執拗にチェックするシーンは通常ほぼありえないし、トリガー時間はリアルタイムに増減するので異常による浪費の影響も一日で終息する。
普通の人には困らないが、稀有な例として絶賛困っているのである。
解決方法は未だない。