Improved Error Handling for API Responses and File Operations

[amanmogal]

trafficstars

This pull request addresses issue [#569] and introduces more robust error handling in util.gs, including:

• Checking for successful API responses to ensure proper functionality.
• Parsing JSON responses with comprehensive error handling to prevent unexpected failures.
• Handling file not found errors gracefully to improve user experience.
• Catching errors when creating calendar events, sending emails, and creating slides to ensure smooth operation across all functionalities.

[amanmogal]

One issue related to this Automate Google Workspace tasks with the Gemini API Codelab hasn't updated the model from gemini-1.0-pro-vision to gemini-2.0-flash.

[Giom-V]

One issue related to this Automate Google Workspace tasks with the Gemini API Codelab hasn't updated the model from gemini-1.0-pro-vision to gemini-2.0-flash.

@amanmogal Can you give me the link? I'll check if I can update it myself. Nevermind I found it and ask for edit access.

[Giom-V]

@amanmogal Thanks a lot for the submission. I have mixed feelings about them as I kinda feel like adding try ... catch everywhere adds some complexity and makes the code sample harder to read. But maybe it makes sense in this case as it's mostly meant to be copy-pasted in the script editor anyway... Give me some time to sort my thoughts and I'll come back to you.

[Giom-V]

Assigning to @markmcd who was the original author of that script.

[markmcd]

@amanmogal Thanks a lot for the submission. I have mixed feelings about them as I kinda feel like adding try ... catch everywhere adds some complexity and makes the code sample harder to read. But maybe it makes sense in this case as it's mostly meant to be copy-pasted in the script editor anyway... Give me some time to sort my thoughts and I'll come back to you.

I agree with this, it is why we didn't add this code in the first place. The intention of the explanatory code in this repo is not to show how to build a hardened production app, but to show how to use the Gemini API. If something goes wrong, it's OK to fail quickly and obviously (e.g. by bubbling the default exceptions). And we can make some assumptions, like that the API will always return JSON.

I can't see any cases here that address Gemini API specific error scenarios. An example of Gemini-specific error would be not to check that every field is populated on a response, but to check if there are any candidates, and if not, return the error from the API response (instead of a generic Unexpected API response format).

It's the same with the test* functions, they are only meant to be run by hand in the console, so they don't need to repeat the error or special-case the responses - they should fail quickly.

If there's some specific cases that you think need to be addressed - please point them out. Normally we would expect a bug report to be attached so we know that the solution is relevant to the problem.

[github-actions[bot]]

Marking this pull request as stale since it has been open for 14 days with no activity. This PR will be closed if no further activity occurs.

[github-actions[bot]]

This pull request was closed because it has been inactive for 27 days. Please open a new pull request if you need further assistance. Thanks!