Remove "impossible" IOException in readTree() and readValue() ObjectMapper methods which accept Strings

[matthew-pwnieexpress]

Unless I'm missing something, methods which read from Strings should never be able to throw an IOException. It seems like it would be a nice API improvement if such ObjectMapper no longer threw the (checked) IOException, which must be explicitly handled and ignored. I'm not 100% sure, but this might also apply to the byte[] methods as well.

Relevant methods:

• readTree(String)
• readValue(String, _)

[cowtowncoder]

@matthew-pwnieexpress True, although the problem is that methods it has to call on JsonParser after construction will still declare IOException so trying to remove this exception adds code. Further, JsonProcessingException, a sub-type of IOException, will need to be thrown.

So I don't see much value in adding extra code to slightly reduce declaration of kinds of exceptions that may be thrown.

[matthew-pwnieexpress]

@cowtowncoder Sure. Though there is already the workaround in place for writing the value as String/byte[], so there is prior art/existing API using this pattern within the class.

[cowtowncoder]

True. I'll have a look when I get chance.

[johnlinp]

+1 for this.

I feel kind of awkward in the following scenario:

try {
    JsonNode jsonNode = mapper.readTree(jsonString);
}
catch (JsonProcessingException e) {
    // sure, I can handle this.
}
catch (IOException e) {
    // what should I do?
}

Or this:

try {
    JsonNode jsonNode = mapper.readTree(jsonString);
}
catch (IOException e) {
    // actually handling JsonProcessingException
}

Both code snippets are weird for me.

[cowtowncoder]

Quick note: Jackson 3.x will change JsonProcessingException into unchecked one, see #2177, and wrap IOException, so this particular problem will be solved.

But we can definitely consider changes to byte[] and String for 2.10 now. I will add this to one of "simple" issues on WIP list at https://github.com/FasterXML/jackson-future-ideas/wiki/Jackson-Work-in-Progress

[johnlinp]

@cowtowncoder Thanks for the explanations. Very helpful.