This would need to apply to d3.text and probably every other fetch helper too, but I haven’t thought through yet whether this is the right approach.

@mbostock I've checked and none of the other Response methods throw an exception but returns an empty object of the respective type.

👉 https://beta.observablehq.com/@herrstucki/204

The spec seems clear that throwing is the desired behavior here, which would make it your responsibility to handle this condition. Related: whatwg/fetch#113 JakeChampion/fetch#123 node-fetch/node-fetch#165

The downside is that you’d have to handle it at the Fetch layer rather than at the d3-fetch layer, since presumably you’d want to check the response status code rather than catching any SyntaxError. So that might be an argument to return undefined rather than throwing… (I think undefined is more appropriate than null here.)

Yeah, that was my thinking too … and since d3-fetch already is an abstraction (and checks for response.ok), I think this would be the right place to handle it.

Superseded by #18.