Improved diagnostic for invalid JSON?

[sharplet]

Sometimes I get an invalid JSON response from the API and it's not clear why (for example, a HTML error page where there would normally be a JSON body). Here's the error message I currently see:

Swish.SwishError.InvalidJSONResponse(Error Domain=NSCocoaErrorDomain Code=3840 "JSON text did not start with array or object and option to allow fragments not set." UserInfo={NSDebugDescription=JSON text did not start with array or object and option to allow fragments not set.})

I think it would be useful to see the actual response decoded as a string in this case. Would that be a useful addition to Swish?

[gfontenot]

So right now we're just attaching the NSError. If you think it'd be useful to also attach the data (which might make more sense than a string?) then I'm good with that.

[sharplet]

If a textual representation is possible, I think that would be preferable in an error message. What about attempting to decode it as a string first, then falling back to just attaching the data? Or attaching data anyway, and optionally decoding as a string?

[gfontenot]

If a textual representation is possible, I think that would be preferable in an error message.

I'm just not sure that's an assumption we can make? I'm also less concerned with just being able to print it quickly and more interested in giving the end user the ability to debug with as much info as possible. Seems like the end user could print or po the decoded string if they needed to? And then if they can't do that, there's more debugging info available for them on their end, because they still have the raw data.

[sharplet]

Here's where I'm coming from: if I'm debugging, and an error occurs, and I can immediately see the details of the response that failed, that's super valuable to me. If I've got an opaque blob of data and I have to go decode it myself in the debugger or insert print statements or something, it's less convenient.

And then if they can't do that, there's more debugging info available for them on their end, because they still have the raw data.

Maybe it doesn't have to be either/or? I kind of think of the string decoding as a progressive enhancement, which doesn't necessarily need to replace the raw data.

It's also possible that string decoding could be a debug-builds-only feature.