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
smime.p7s
Description: S/MIME cryptographic signature
