回答
寫在評論你的問題,那是不可能的。但是,您可以在執行開始時在scriptDB或屬性中設置一個標誌,並在執行到正常結束時清除該標誌,這樣您可以在下次運行時發現腳本在最後一次運行時正常結束時間並嘗試採取糾正措施,如果沒有。
上面的答案是正確的;這是不可能的。 pbhd提到的解決方法的一個簡單替代方法是簡單地跟蹤腳本的運行時間(例如定期比較new Date().getTime()
的結果),然後在達到最大執行時間之前運行包含在catch
語句中的任何內容。最長6分鐘(reference)。
這樣,你不必捕捉錯誤 - 你可以搶佔它。
在正常測試期間,可能會意外創建一個消耗每日執行時間限制100%的無限循環(或非常長的循環)循環。
即使你知道你有什麼圓頂錯立即,你不能馬上與谷歌的腳本另外24小時重新嘗試 - 因而顯著放緩持續發展,也許迫使開發商做一些其他的工作,把他的重點/「注意力流」從目前的問題中解放出來。這幾乎總是不好的。
我的產品(「IBM OLIVER CICS測試/調試」 - 見Wikipedia article)大約37年前 - - 解決了這個問題 - 和許多其他具有任何特定交易的時間限制和攔截導致超時,允許的選項: - 或
- 延續
- 檢查/修改變量
- 「手動」 重試(同一時間)或
- 中止。
谷歌可以很容易地實現這種方法 - 如果執行時間看起來太重了,可以「暫停」。我對OLIVER中的其他資源有類似的解決方案 - 例如過多的API調用(「可能的宏循環」)和過多的內存使用。
似乎需要像我這樣的「老式計時器」來解決已存在的問題「從一開始就存在」(當然還有PC的想法之前)。
谷歌目前的「解決方案」(即絕對限制)只能幫助谷歌保持自己的服務器不被淹沒。他們很容易就能做到OLIVER多年前做的事情。順便說一下,在Wikipedia文章中不應該有「IBM」前綴 - 這是我自己的產品,一些小丑維基百科編輯器將它改爲包含前綴。(順便說一下,Google不會阻止其他腳本運行在相同的s/s上 - 也許只能使用最小的額外時間(即同一電子表格中的腳本仍然有效)。我試着重命名原始腳本作爲一個實驗,但它是一個很短的時間內「超過執行時間」錯誤後停止
GIZ-A-JOB谷歌 - 你知道它值得
我沒有得到這個答案,看起來像是在吹噓我。 – Adelin
- 1. curl_multi_exec最大執行時間超過
- 2. 函數超過最大執行時間
- 3. 最大的執行時間超過
- 4. 獲得最大的執行時間超過了Drupal的鏈接
- 5. PHP:最大執行時間0超出
- 6. OpenTBS超出最大執行時間
- 7. 超過最大執行時間的大型數據集
- 8. ExtJS當查詢執行時間超過超時時捕獲事件
- 9. PHP捕獲最大執行時間錯誤
- 10. PHP致命錯誤:最大的執行時間超過
- 11. 超過laravel的最大執行時間爲120秒5.2
- 12. 最大的執行時間超過了僅在第二次
- 13. 樹建築功能超過最大執行時間
- 14. 致命錯誤:超過30秒的最大執行時間
- 15. FFmpeg文件轉換超過最大執行時間
- 16. 致命錯誤:超過400秒的最大執行時間
- 17. 致命錯誤:超過0秒的最大執行時間
- 18. 在php中超過了300秒的最大執行時間
- 19. 由於會話啓動,最大執行時間超過了?
- 20. TCPDF最大執行時間超過30秒
- 21. 最大的執行時間超過誤差
- 22. Google表單的腳本 - 最大執行時間超過
- 23. PHP SSH2:超過30秒的最大執行時間
- 24. 多維數組超過最大執行時間
- 25. 移動陣列內部指針超過最大執行時間
- 26. 超過300秒的最大執行時間
- 27. PHP imagick註釋setFont超過最大執行時間
- 28. 致命錯誤:超過x秒的最大執行時間
- 29. Concrete5.7棧 - PHP最大的執行時間超過
- 30. Facebook的圖形錯誤最大的執行時間超過
不知道你怎麼可以! - 你已經走了超過限制,允許更多的代碼在catch塊中執行只允許人們跳過限制,並且運行時沒有任何限制 –