IMHO if a binding error occurs, an exception should be thrown back to
the user code (=fail fast) and spring-richclient shouldn't catch/log etc.
Spring fails fast when you configure a <property name="doesNotExists"...
Hiberante fails fast when you configure an @Temporal on a String.
Neither of them actually logs anything: the exception is thrown back to
the user code (sometimes wrapped, but never eaten or logged). The user
code usually doesn't handle it, so it ends up in the thread uncaught
exception handler which nicely logs it as an error (if
log4j/commons-logging/slf4j is configured, otherwise directly
stacktraces it to sout).
With kind regards,
Geoffrey De Smet
Jan Hoskens wrote:
> Hi all,
>
> While looking at issue RCP-308 and rereading the associated forum thread,
> I get the feeling that we need a BindingException. I'll shortly sketch the
> problem and my idea.
>
> When any exception occurs while setting a value, the exception is caught
> in DefaultFormModel.ValidatingFormValueModel.setValueSilently(). Hereafter
> a binding error is raised, the exception logged as debug and that's it.
> This can be a perfect use-case for some, but it also covers up exceptions
> that may come from any listener attached to that valuemodel (or wrapped
> model). The latter should definitely not be handled as a binding error.
>
> The issue states that the log level should be at least at the warning
> level, which stands out more when developing. This is correct but I think
> we do need more precise handling of errors. We could create a
> BindingException that any PropertyAccessStrategy can throw and catch only
> this exception to raise as a binding error (and log it as warning). All
> others should be passed upwards. So I'm thinking of adding a
> BindingException and using this in the
> BeanPropertyAccessStrategy.setValue(Object) to wrap any exceptions
> concerning the binding to the backing bean.
>
> What do you think?
>
> Kind Regards,
> Jan
>
>
>
> **** DISCLAIMER ****
> http://www.schaubroeck.be/maildisclaimer.htm
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
|