On Friday 16 Dec 2005 02:47, Igor Vaynberg wrote:
> There is in fact an on error handler Application.onRuntimeException(). its
> called whenever there is a runtime exception. instead of trying to do
> try/catch in your filter you can use a request variable to indicate
> success/failure. set it to success, and in the error handler set it to
> failure.
Thanks, this currently looks like the best place to do it.... but it is very
untidy requiring coordination between more than one object using a request
variable etc.
It also means that I must trust the wicket code to always call
Application.onRuntimeException(). It would be much simpler if I could
override a single method to wrap it in a try-catch-finally block.
for example, if Request cycle had a non-final method:
protected void doRequest() throws RuntimeException
{
// Attach thread local resources for request
threadAttach();
// Response is beginning
internalOnBeginRequest();
onBeginRequest();
// If request is parsed successfully
if (parseRequest())
{
// respond with a page
respond();
}
}
I would then feel much better being able to override this method and wrap it
in my try-catch-finally block. Good and safe.
> I use this approach whenever i know my requirements will never
> exceed the single-transaction-per-request limitation.
Do you often need more than one transaction per request?
John
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
