hugo: Failures in getJSON crash the build instead of allowing the user to handle it.

As suggested in #5643 I am creating a new issue for this.

getJSON causes builds to fail and halt in the versions 0.68.3, 0.69.1 and 0.69.2 which I have tested it on. This happens when accessing a remote file at a HTTP address (have not tested for local json files, not my use case).

The use case I have is that we’re checking a database through its REST API for the existence of an entry to pull some metadata, and falling back to local data if not present. However, the only way we can check for the existence is to make a query, and if it’s not there, the getJSON errors, and the build halts.

Specific error is this: Failed to get JSON resource "https://data.rcsb.org/rest/v1/core/entry/": Failed to retrieve remote file: Not Found.

Supposedly #5648 was meant to fix this, but from what I’m reading never did it properly?

I don’t know Go so I’m not sure exactly how to fix it, but I think I can trace its stack:

• getJson calls getResource and then if an error is thrown its supposed to log said error but not throw the error: https://github.com/gohugoio/hugo/blob/c2d9fd1ebef89cc19256e6799f29ab3d27eaf879/tpl/data/data.go#L118-L122
• getResource attempts to call getRemote because the a URL was passed in, so the "" case is skipped and it goes to the default: https://github.com/gohugoio/hugo/blob/c2d9fd1ebef89cc19256e6799f29ab3d27eaf879/tpl/data/resources.go#L109-L122
• getRemote detects an HTTPError and actually throws the error, which passes back up the stack: https://github.com/gohugoio/hugo/blob/c2d9fd1ebef89cc19256e6799f29ab3d27eaf879/tpl/data/resources.go#L55-L57
• getResource and getJSON behave correctly and log the error, but the thing actually halting the build came from the getRemote call and the HTTPError handling.

I have a couple ideas on what behavior I would like to see to make this more user and use-case friendly.

1. Is it possible to make the getRemote on HTTPError not actually throw the error and instead log it, pass it back up and let the calling function handle it? Especially since getRemote isn’t a publicly available function in Hugo’s shortcodes?
2. Could there be some switch to tell the getRemote to pass it back up (like if there is another function invoking which could handle it?)
3. Could the getRemote or getJson throw a warning instead? This does leave it up to the site developer to properly handle the case when the JSON they get back isn’t what they expect, but I think that’s a reasonable thing to ask for.
4. Use a with...else...end construct to handle the return from getJSON when it errors. This actually already works as expected. I can test it with the shortcode construct of

   {{ with getJson "...." }}
       <!-- Do stuff on success -->
   {{ else }}
       {{ warnf "It failed" }}
   {{ end }}
   

   This will correctly throw not only the getJSON error, but also throw the warnf warning in the console. However, the fact that an error was thrown causes the built to fail in the end, but the getJSON error clearly is not fatal to the overall build code.
5. Have a function to probe an external site? Basically a function to see if the url exists. I think getRemote does this already to some extent, but make this return a boolean instead of the result or error?

What version of Hugo are you using (hugo version)?

0.68.3, 0.69.1 and 0.69.2 (currently using)

Sepcifically: Hugo Static Site Generator v0.69.2/extended darwin/amd64 installed via brew

Does this issue reproduce with the latest release?

Yes: 0.69.2