First, thanks for merging that PR. I really appreciate it. > On May 15, 2022, at 11:55 PM, GitBox <[email protected]> wrote: > > > rmannibucau commented on PR #91: > URL: https://github.com/apache/johnzon/pull/91#issuecomment-1127292848 > > @dblevins FYI here is a test showing the comment I made in the PR to > explain why current exception handling is not yet release friendly/ready (and > why I spoke of mutable exception as an option - note that I don't care > instantiating 3-4 instances but I care about instantiating 2 stack traces > since they are often very costly in apps so a MapperExceptionBuilder which > would be a RuntimeException we catch internally and `.build()` to a > MapperException after having saved the context in the `Mapper` instance or > alike would perfectly work if you don't want to make `MapperException` > mutable on user side - which is a very fair point): > https://github.com/apache/johnzon/commit/c2bf6945c2ca43befa93e15d821e0dee439aa8de#diff-9a970ccae72ea07cf4f226b1066a425fda9d97f48e06f1bc6f12079da28ca2f4R38
Can you help me understand the issue with wrapping exceptions when they are a subtype of MapperException? If you really wanted to rewrite the code so it uses some sort of mutable message, I'd say I wouldn't recommend it, but I wouldn't stand in the way either. I'm just not clear on what issue we're solving. -David
smime.p7s
Description: S/MIME cryptographic signature
