You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Per Huss (JIRA)" <ji...@apache.org> on 2017/10/04 11:59:00 UTC

[jira] [Created] (WICKET-6477) Component.getDefaultModelObject() wraps in RuntimeException instead of WicketRuntimeExcpetion

Per Huss created WICKET-6477:
--------------------------------

             Summary: Component.getDefaultModelObject() wraps in RuntimeException instead of WicketRuntimeExcpetion
                 Key: WICKET-6477
                 URL: https://issues.apache.org/jira/browse/WICKET-6477
             Project: Wicket
          Issue Type: Bug
          Components: wicket
    Affects Versions: 7.9.0
            Reporter: Per Huss
            Priority: Minor
         Attachments: componentexception.zip

If a model throws an exception when wicket tries to get the model value during rendering using Component.getDefaultModelObject() the original exception will be wrapped in a vanilla RuntimeException. This will then be wrapped again in a WicketRuntimeException. Perhaps there is a reason for this behaviour that I'm not aware of, or perhaps it's just accidental? I would expect the getDefaultModelObject() to wrap directly in a WicketRuntimeException, which will propagate the wicket stack properly without further wrapping.

My use case is a SessionTimeoutException (originating from a timed out session to a third system) that depending on which path wicket has travelled when the exception is thrown, it is sometimes wrapped directly in a WicketRuntimeException and sometimes wrapped in a RuntimeException wrapped in a WicketRuntimeException. This can be handled by the top level exception handler of course, but requires more complexity and may offer a few runtime WTFs...

Changing Component.getDefaultModelObject() to throw a WicketRuntimeException should be fairly safe since it is a RuntimeException and it will avoid the redundant wrapping.

Unit test quickstart attached. 

Last: Thank you for awesomeness!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)