Hi, Recently I had the chance to review some customer applications and I've noticed a pattern in both applications:
a custom impl of IRequestCycleListener#onException() checks whether the given exception is instance of something that the application knows how to deal with and if it is not then a RenderPageRequestHandler is returned trying to render the last successfully rendered page. I.e. the idea is to show something like an error feedback in the last/current page instead of redirecting to InternalErrorPage. The problem in both impls was that internal/special exceptions like ResponseIOException, PackageResource.PackageResourceBlockedException and StalePageException (and maybe ListenerInvocationNotAllowedException, AuthorizationException) have been managed by the custom code instead of letting Wicket to do its business (in DefaultExceptionMapper). The fix was to add a check for these exceptions and do nothing. But Wicket can add more such special exceptions in the future and the application logic may break... What do you think about introducing a special marker interface for all exceptions which represent some erroneous state and be better handled by Wicket rather than by custom code ? This way a new exception type will handled automatically in the future. Or maybe you have a better idea ? Martin Grigorov Wicket Training and Consulting
