Exception on empty input stream or string

[Spikhalskiy]

Now code like

OpenRtbJsonFactory.create().newReader().readBidRequest("");

leads to

com.fasterxml.jackson.core.JsonParseException: Expected start of object
 at [Source: com.google.common.io.CharSequenceReader@1cab0bfb; line: 1, column: 1]
    at com.google.openrtb.json.OpenRtbJsonUtils.startObject(OpenRtbJsonUtils.java:47)
    at com.google.openrtb.json.OpenRtbJsonReader.readBidRequest(OpenRtbJsonReader.java:132)
    at com.google.openrtb.json.OpenRtbJsonReader.readBidRequest(OpenRtbJsonReader.java:112)
    at com.google.openrtb.json.OpenRtbJsonReader.readBidRequest(OpenRtbJsonReader.java:105)

which is not a bug, but it's not easy to use, if I want to have null in this case I should firstly check stream in my code. Would be great to have some built-in ability like (similar to Jackson features)

OpenRtbJsonReader#enableFeature(OpenRtbParseFeatures.EMPTY_INPUT_AS_NULL)

[opinali]

I agree this would be a nice improvement... normally, the read method should return null for empty string, because an empty string is not a valid representation of any JSON object (an "empty" JSON object must contain at least {}). But it's nasty to make the reader methods @Nullable only for this special case. I think we can just return BidRequest.getDefaultInstance(), which also doesn't require special casing in the caller. (The default instance is a fixed object, so you can detect if that was the returned object if you care.)

[Spikhalskiy]

an empty string is not a valida representation of any JSON object

Sure, that is why we definitely shouldn't return BidRequest with default content here

But it's nasty to make the reader methods @nullable only for this special case.

I'm not sure. Reader return "nothing" only if there is "nothing" in input and only in this case. So, this case is enough for Nullable from my perspective.
I don't like "defaultInstance" solution, because it's

1. looks like a hack and magic object
2. "{}" is default object ideologically, so we need getEmptyInstance and it's definitely looks like a hack because empty object is null

Accuracy to Nullable - this is why I suggest to make it as feature that user can enable. In default behavior we never return null and throw and exception (but maybe rework to throw some specific like EmptyInputException), but if user explicitly enable parsing empty input as null - we will return null.

[opinali]

Some good points... returning the default object is clean in the theory because the Protobuf library documents that this thing is a singleton; still, I agree it's not a popular and obvious API design.

Now, an empty string is not a valid JSON input, so the exception you get today is the perfect behavior for strict parsing. Unfortunately there's no good way to detect the cause of Jackson's exceptions, other than matching the message strings, otherwise I would dismiss this as WAI. We already have a "strict" option in the API, so that's a perfect candidate for the desired feature: do setStrict(false), then the read methods will mask this special case and return null. I'm still not friendly to the idea of making the return types @Nullable for the sake of a corner case (if you have some exchange/platform sending you empty-string requests or responses they are doing it wrong...), but I suppose it's not a big sin to return null without declaring @Nullable if the user has set a strict=false option; that opens the Pandora box of "I know what I'm doing" so it looks like a good tradeoff.

[opinali]

(0.9.6 improved this; closing bug.)