Exception on empty input stream or string about openrtb HOT 4 CLOSED

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.)

from openrtb.

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.

from openrtb.

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.

from openrtb.

(0.9.6 improved this; closing bug.)

from openrtb.