Closed agentgt closed 1 week ago
I kind of like bc we don't have super long stacktrace by not wrapping the exception.
Yeah I'm concerned it somehow might impact performance.
I think if one wanted it they could just wrap a context with a ForwardingContext and do their own exception wrapping?
EDIT I should say I don't know if it really would impact performance but I have seen where doing something like:
try {
blah.doSomething();
catch(Exception e) {
throw new SomeException("...", e);
}
Slows down things especially given some of those calls are converting string to native.
yea that is what I tried to avoid and the reason of SneakyThrows.propagate
yea that is what I tried to avoid and the reason of SneakyThrows.propagate
Yes I use this technique as well in some other libraries.
I think the ForwardingContext
is the best solution for this and I think it will work (and override convert
).
I will close this issue once I make sure that option can work.
No I guess ForwardingContext will not work as query()
, form()
etc take the concrete Context
(this
).
When a
SingleValue
does its conversion it is painful to figure out which parameter actually caused the exception even thoughSingleValue
has thename
.In
SingleValue
we have:In theory we do not need to change API at all but have the builtin converters check if the passed in
this
has aValue.name()
and wrap the exception.