Hi, Strictly speaking - not saying we can't change it - it was the intent. Rational (keep in mind originally point was that converter (string) were always sufficient but jsonb made it complicated) was that binding null - JsonValue.NULL, too big data, java out of bound value, .... - is ok but serializing something in an object as null was a bug (lost of data).
Now where it gets complicated: 1. Spec - jsonb - is ambiguous even if yasson supports null both ways 2. We cant break users by default (means a JsonbConfig toggle, default being backward compat I'd say) if we want to support it Hope it helps a bit Romain Le mar. 17 mai 2022 à 05:42, David Blevins <[email protected]> a écrit : > There was one scenario from the report that I'd love to get some thoughts > on if it is a bug or not. > > We have some asymmetry on how we handle nulls to/from Adapter, Converter > and JsonbAdapter. If it's a bug, I'll go hunt it down and submit a fix, > file jiras, etc. > > > - Converter > - toString returning null fails > - fromString returning null ok > > - Adapter > - B from(A) returning null B fails > - A to(B) returning null A ok > > - JsonbAdapter > - B adaptToJson(A) returning null B fails > - A adaptFromJson(B) returning null A ok > > So, bug or not bug? > > My $0.02 is it seems like a bug. > > > -David > > > On May 9, 2022, at 2:40 AM, David Blevins <[email protected]> > wrote: > > > > All, > > > > Can you take a look at the bold lines towards the bottom of these two > documents? > > > > Mapper API handling of exceptions throw by users or during > deserialization > > > > - https://gist.github.com/dblevins/3fbad79900e75e1970d32c9681657e5e > > > > Jsonb API handling of exceptions throw by users or during deserialization > > > > - https://gist.github.com/dblevins/ace48ca0aeb1e9e2b22d3bc31fee7d07 > > > > > > Most everything that is not titled "deserialization" is testing what can > be caught if the user throws a RuntimeException from their code, say via a > setter, getter, constructor, adapter, serializer, etc. > > > > Where you see "MyException" it indicates the user cannot catch > MapperException or JsonbException, but instead must/may catch their > exception directly. It's the proposal that all of these get converted to > either MapperException or JsonbException to make them more consistent with > 90% of the other scenarios, but also so we can improve the error messages. > > > > Where you see NullPointerException, there is most likely a bug that > needs fixing. Our Converter/Adapter code can handle nulls in one > direction, but not the other. Likely, no exception is the best course. > > > > Where you see MapperException in the JsonbAPI-Exceptions.adoc, that also > seems like a bug. It should probably at least be JsonbException. > > > > Let me know if you think the recommendations are good or bad. > > > > > > -David > > > >
