Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JsonParser does not document exception handling #1353

Open
elharo opened this issue Apr 29, 2021 · 8 comments
Open

JsonParser does not document exception handling #1353

elharo opened this issue Apr 29, 2021 · 8 comments
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: docs Improvement to the documentation for an API.

Comments

@elharo
Copy link
Contributor

elharo commented Apr 29, 2021

JsonParser.parseAndClose and similar methods do not document which exceptions are thrown under what circumstances. The Jackson and GSON subclasses are in fact throwing different exceptions, IO and IllegalArgument to name two, for the same input. This needs to be documented and made consistent.

@elharo elharo added type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. type: docs Improvement to the documentation for an API. labels Apr 29, 2021
@Neenu1995 Neenu1995 added the priority: p2 Moderately-important priority. Fix may not be included in next release. label Apr 29, 2021
@chingor13
Copy link
Collaborator

@elharo
Copy link
Contributor Author

elharo commented Apr 29, 2021

That sounds like a good idea.

@hiranya911
Copy link
Contributor

Also related to this is that the same parser input may or may not throw depending on the underlying library used. For example given a plain text input like String input = "not json";, Jackson would throw, but Gson would not. Some of this is due to the differences in the parsers themselves (Gson is lot more lenient by default, although this can be configured). But it would be nice if the JsonFactory abstraction can hide such differences better.

@elharo
Copy link
Contributor Author

elharo commented Apr 29, 2021

GSON is not as configurable as its docs claim. In particular, the API doc for setLenient doesn't appear to match its actual behavior.

@hiranya911
Copy link
Contributor

At least the simple case below works as expected when setLenient(true) is not set:

JsonReader reader = new JsonReader(new StringReader("not json"));
reader.hasNext();

This throws:

com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 1 path $
	at com.google.gson.stream.JsonReader.syntaxError(JsonReader.java:1564)
	at com.google.gson.stream.JsonReader.checkLenient(JsonReader.java:1405)
	at com.google.gson.stream.JsonReader.doPeek(JsonReader.java:594)
	at com.google.gson.stream.JsonReader.hasNext(JsonReader.java:415)

@elharo
Copy link
Contributor Author

elharo commented Apr 29, 2021

I'd like to introduce a JsonException class to distinguish I/O errors from JSON parsing errors since a JSON syntax violation is not an I/O error. However this would not be API compatible. :-(

@yoshi-automation yoshi-automation added 🚨 This issue needs some love. and removed 🚨 This issue needs some love. labels Jul 29, 2021
@lesv
Copy link
Contributor

lesv commented Sep 20, 2021

@BenWhitehead @vam-google Should this be assigned to one of you?

@lesv lesv added priority: p3 Desirable enhancement or fix. May not be included in next release. and removed type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. priority: p2 Moderately-important priority. Fix may not be included in next release. labels Sep 20, 2021
@yoshi-automation yoshi-automation added 🚨 This issue needs some love. and removed 🚨 This issue needs some love. labels Mar 19, 2022
@Capstan
Copy link
Contributor

Capstan commented Jun 7, 2022

In the monorepo, I am attempting to migrate the entirety from Jackson and Jackson2 to Gson, in part because this repo has already deleted Jackson support and in part because of pressure from security. I am running into this case (and others documented in googleapis/google-api-java-client#1779). Do you all have a general plan for what you would do here if you were to tackle it?

My choices are to instrument the consumers' code (where I can figure out where it's relevant, which is difficult) to handle the additional IllegalArgumentException, or catch and rethrow in the GsonParser via a patch to be upstreamed. If you were going to aim at the latter or something similar, I'd be more inclined to approach things that way, so that the wide change can be more safely applied.

Capstan referenced this issue in googleapis/google-api-java-client Jun 18, 2022
* use GSon instead of Jackson

* remove jackson2

* fix callback
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: docs Improvement to the documentation for an API.
Projects
None yet
Development

No branches or pull requests

7 participants