Any feedback on how to move forward with PR #91?
-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 >
smime.p7s
Description: S/MIME cryptographic signature
