fix: handle errors in response parsing in xhr loader

[sebakerckhof]

Although I'm not sure if/what the OWS spec says about this, but at least the popular geoserver will return status 200 even when the result is an OWS exception report.

E.g. If I make a WFS call that fails in geoserver. I'll get a status 200 with an ows exception report XML.
e.g.

<?xml version="1.0" encoding="UTF-8"?><ows:ExceptionReport xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ows="http://www.opengis.net/ows" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0.0" xsi:schemaLocation="http://www.opengis.net/ows localhost/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd">
  <ows:Exception exceptionCode="NoApplicableCode">
    <ows:ExceptionText>We have had issues trying to flip axis of GEOGCS["GCS_WGS_1984", ...</ows:ExceptionText>
  </ows:Exception>
</ows:ExceptionReport>

The problem is that the xhr loader does not account for this and will throw an uncaught error when trying to parse it as json.
Therefore the failure/success callbacks are never called and the source stays in loading state (and in turn rendercomplete is not called)

This PR tries to solve this by putting wrapping the entire data parsing in a try-catch

[github-actions]

📦 Preview the website for this branch here: https://deploy-preview-15808--ol-site.netlify.app/.

[sebakerckhof]

Striclty speaking this if-else is not needed anymore, since a falsy source would throw an error which is then caught and calls failure();, but it seemed cleaner to keep it.

[ahocevar]

@sebakerckhof A slightly related note: for GeoServer, when requesting WFS in JSON format, you should configure it to also return exceptions in JSON. See https://docs.geoserver.org/latest/en/user/services/wfs/reference.html#exceptions. That does not change the response status code though.

It would be good if you could change the test to use the JSON version of the exception. Also, there is no need to call JSON.parse() in the featureloader, because the format will handle that. Also for XML formats, there is no need to parse the XML. Simplifying that would make the code easier to read, I think.

[sebakerckhof]

Ah, I didn't know about that option, thanks. But indeed, it doesn't change the need for the try-catch that this PR adds.

I added a test for the json exception, but kept the xml test as well, since it's not wrong for the server to send an xml report from what I got from the spec.

The redundant parsing is removed now.

[ahocevar]

Thanks, @sebakerckhof