Hello,
I've been working on an error page in Apache Wicket and came across a
general pattern in Apache Wicket and I'd like to understand the reason for
it.
Exceptions in Apache Wicket do not have a single class hierarchy; i.e.
there are exceptions that eventually extend WicketRuntimeException
what is the purpose of knowing whether an exception is a wicket
exception or something from further down the stack?
eg how would you handle a runtime exception that came from within
java.lang.String differently then the one that came from Wicket or the
one that came from the servlet api?
-igor
More clearly, the intention is to be able to distinguish exceptions from
Apache Wicket and other frameworks and not really handle them. For
instance, there can be two exceptions: MarkupException and
CouldNotLockPageException. Both are in the context of Apache Wicket,
however, we actually need to
On Wed, May 1, 2013 at 1:23 AM, Behrooz Nobakht nob...@gmail.com wrote:
More clearly, the intention is to be able to distinguish exceptions from
Apache Wicket and other frameworks and not really handle them.
for what purpose? an unhandled exception is an unhandled exception...
For
instance,
Thanks for the reply.
The purpose is that when it's determined that exception comes from Wicket,
the error page (1) can reduce the cause chain (which can be independent of
Apache Wicket of course), and (2) based on this information provide the
user to report a bug or email the stack trace to a
how is this different than handling an exception that comes from say javax.mail?
-igor
On Wed, May 1, 2013 at 2:48 AM, Behrooz Nobakht nob...@gmail.com wrote:
Thanks for the reply.
The purpose is that when it's determined that exception comes from Wicket,
the error page (1) can reduce the
