You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by aditsu <ad...@yahoo.com> on 2008/11/03 13:24:48 UTC
Handling exceptions during render
Hi, how can I catch any exception thrown while a component is rendering, and
either hide the component or show an error message, but allow the rest of
the page to render?
Modifying or replacing each such component is not an option, I need a
general way to handle exceptions while rendering any unknown component or
child component. Such as a getObject method from a model throwing a runtime
exception.
Adrian
--
View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20301737.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by Alex Objelean <al...@isdc.ro>.
Sorry for mistake... I've updated the comment
aditsu wrote:
>
> Thanks, but I can't find any handleRuntimeException method in any class.
> I'm using wicket 1.4-m3.
> Also, if the method is private, then how can I possibly override it?
>
>
> Alex Objelean wrote:
>>
>> There are more threads about this issue...
>>
>> In order to catch all runtime exception, you have to override default
>> RequestCycle (newRequestCycle method) in your application class and
>> override <private Page handleRuntimeException(final Page page, final
>> RuntimeException e)> method.
>>
>>
>> Alex Objelean
>>
>
>
--
View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20302752.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by aditsu <ad...@yahoo.com>.
Thanks, but I can't find any handleRuntimeException method in any class. I'm
using wicket 1.4-m3.
Also, if the method is private, then how can I possibly override it?
Alex Objelean wrote:
>
> There are more threads about this issue...
>
> In order to catch all runtime exception, you have to override default
> RequestCycle (newRequestCycle method) in your application class and
> override <private Page handleRuntimeException(final Page page, final
> RuntimeException e)> method.
>
>
> Alex Objelean
>
--
View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20302652.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by Alex Objelean <al...@isdc.ro>.
If you return null in onRuntimeException -> the stack trace will be shown.
But if you will return a page instance, the application will redirect you to
this page. For instance:
[CODE]
@Override
public Page onRuntimeException(final Page page, final RuntimeException
e) {
//do something
return new LoginPage();
}
[/CODE]
The above example will redirect you to the LoginPage if any runtime
exception occures.
aditsu wrote:
>
> Ok, but how would that let me render the rest of the page?
>
>
> Alex Objelean wrote:
>>
>> There are more threads about this issue...
>>
>> In order to catch all runtime exception, you have to override default
>> RequestCycle (newRequestCycle method) in your application class and
>> override onRuntimeException method.
>>
>> Example:
>> [CODE]
>> @Override
>> public RequestCycle newRequestCycle(final Request request, final Response
>> response) {
>> return new WebRequestCycle(this, (WebRequest) request, (WebResponse)
>> response) {
>> @Override
>> public Page onRuntimeException(final Page page, final
>> RuntimeException e) {
>> //do something
>> return null;
>> }
>> }
>> }
>> [/CODE]
>>
>>
>> Alex Objelean
>>
>
>
--
View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20302777.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by Erik van Oosten <e....@grons.nl>.
Yeah, I was afraid it would come to that.
Sorry, you've apparently done some more research already...
Another thing I sometimes do is take the Wicket class and put it in the
web-project's classpath but with my changes (e.g. remove a final). All
servlet containers will load earlier from the WEB-INF/classes folder
then from WEB-INF/lib. Its a huge hack, but it works most of the time.
Regards,
Erik.
aditsu wrote:
> Well, I'm specifically talking about unexpected runtime exceptions. I don't
> want those to destroy the whole page.
> They can kill a component, that's ok, but the rest of the page should work.
> And yes I want to "make sure that no exceptions are thrown", except that's
> not so simple when you're dealing with a complex site and lots of pages,
> components and models. If I missed any exceptions, I want those to be
> handled gracefully rather than redirecting to an error page.
>
> renderAll is ONLY called on the page, all other components go through
> renderComponentTagBody to call renderNext, and both renderComponentTagBody
> and renderNext are final :(
> I tried overriding onComponentTagBody and wrapping the super invocation with
> try/catch, but then the markup gets broken because it doesn't close tags
> (i.e. advance in the markup stream?) after the exception is thrown in a
> child component, and I still get an error page :(
> renderComponent(MarkupStream) is final too, it seems that all "doors" are
> closed and locked...
>
>
>
--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by aditsu <ad...@yahoo.com>.
aditsu wrote:
>
> Anyway, I want to have the option to catch exceptions from child
> components at certain points that I can define. And I think I got a new
> idea.. involving replace and RestartResponseException
>
Well, it seems to work, except I had to call setAuto(true) on the
replacement component, to avoid a "Cannot modify component hierarchy after
render phase has started (page version cant change then anymore)" exception.
I'm not entirely sure what setAuto does, I hope it doesn't break anything in
this case.
What does that exception mean anyway?
Adrian
--
View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20336613.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by aditsu <ad...@yahoo.com>.
igor.vaynberg wrote:
>
> i would hate a user to look at a signup form without a signup button
> because something inside it caused an error.
>
> i would also hate to see a user at a checkout page with a missing
> $500.00 discount amount shown because there was an error in the
> discount label.
>
Some forms can be submitted by pressing enter, but anyway, there are indeed
cases where removing a small component is not a good idea.
It's probably better to replace the whole form or the whole checkout list
with an error message, or in some cases replace/redirect the whole page (the
current behavior).
Anyway, I want to have the option to catch exceptions from child components
at certain points that I can define. And I think I got a new idea..
involving replace and RestartResponseException
Adrian
--
View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20336435.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by Igor Vaynberg <ig...@gmail.com>.
i would hate a user to look at a signup form without a signup button
because something inside it caused an error.
i would also hate to see a user at a checkout page with a missing
$500.00 discount amount shown because there was an error in the
discount label.
showing a "mostly" constructed page does not sound like a good idea to
me because you are opening pandora's box, unless of course, you can
anticipate and account for all possible ways in which a page can
break. but then again, like you said, as soon as you do it will find
another unexpected way to break.
-igor
On Tue, Nov 4, 2008 at 11:19 AM, aditsu <ad...@yahoo.com> wrote:
>
>
> Alex Objelean wrote:
>>
>> Can you be more specific? What kind of unexpected runtime exceptions are
>> you talking about? I don't think I understood you correctly.
>>
>
> It could be anything.. NPE (probably the most popular),
> IllegalArgumentException and its descendants, ArithmeticException,
> ClassCastException, IndexOutOfBoundsException etc... or a wrapper for a
> checked exception.
> It can happen in the application code or can be thrown from library code.
> As for the reasons.. again there are lots of possibilities: invalid input,
> buggy code, invalid data received from 3rd party, unhandled edge case,
> unavailable resource, high load, etc.
>
>
>
>> Any runtime exception thrown by the wicket is caused by a programming
>> error... there is no sense to catch it without fixing the problem in your
>> code.
>>
>
> That sounds foolish to me, unless you consider any failure to handle any of
> the situations described above, to be a programming error.
> And I disagree a LOT more about the second sentence: usually when an
> application is launched, it already passed some kind of testing which found
> everything to be working well, and the application works well for a while,
> then an unexpected exception happens. These exceptions in production are
> very good friends of Murphy and tend to follow several laws, such as:
> - Whatever can go wrong will go wrong, and at the worst possible time, in
> the worst possible way
> - Every non trivial program has at least one bug
> - If you perceive that there are four possible ways in which something can
> go wrong, and circumvent these, then a fifth way, unprepared for, will
> promptly develop
> - If the input editor has been designed to reject all bad input, an
> ingenious idiot will discover a method to get bad data past it
> So anyway, when (not if) the unexpected exception is thrown in production
> code, what would you rather have the users see (whether there are 10, 1000
> or 10000000 users)? A big "internal error" page? Or a mostly-working page,
> but with one part missing or showing an error message? Especially if access
> to that same page is required in order to fix the problem!
> --
> View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20327592.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by aditsu <ad...@yahoo.com>.
Alex Objelean wrote:
>
> Can you be more specific? What kind of unexpected runtime exceptions are
> you talking about? I don't think I understood you correctly.
>
It could be anything.. NPE (probably the most popular),
IllegalArgumentException and its descendants, ArithmeticException,
ClassCastException, IndexOutOfBoundsException etc... or a wrapper for a
checked exception.
It can happen in the application code or can be thrown from library code.
As for the reasons.. again there are lots of possibilities: invalid input,
buggy code, invalid data received from 3rd party, unhandled edge case,
unavailable resource, high load, etc.
> Any runtime exception thrown by the wicket is caused by a programming
> error... there is no sense to catch it without fixing the problem in your
> code.
>
That sounds foolish to me, unless you consider any failure to handle any of
the situations described above, to be a programming error.
And I disagree a LOT more about the second sentence: usually when an
application is launched, it already passed some kind of testing which found
everything to be working well, and the application works well for a while,
then an unexpected exception happens. These exceptions in production are
very good friends of Murphy and tend to follow several laws, such as:
- Whatever can go wrong will go wrong, and at the worst possible time, in
the worst possible way
- Every non trivial program has at least one bug
- If you perceive that there are four possible ways in which something can
go wrong, and circumvent these, then a fifth way, unprepared for, will
promptly develop
- If the input editor has been designed to reject all bad input, an
ingenious idiot will discover a method to get bad data past it
So anyway, when (not if) the unexpected exception is thrown in production
code, what would you rather have the users see (whether there are 10, 1000
or 10000000 users)? A big "internal error" page? Or a mostly-working page,
but with one part missing or showing an error message? Especially if access
to that same page is required in order to fix the problem!
--
View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20327592.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by Alex Objelean <al...@isdc.ro>.
Can you be more specific? What kind of unexpected runtime exceptions are you
talking about? I don't think I understood you correctly.
Any runtime exception thrown by the wicket is caused by a programming
error... there is no sense to catch it without fixing the problem in your
code.
Catching runtime exception could make sense if the runtime exception is
thrown by some business logic you are invoking inside wicket components....
but this kind of issue is your responsibility..
Alex Objelean
aditsu wrote:
>
> Well, I'm specifically talking about unexpected runtime exceptions. I
> don't want those to destroy the whole page.
> They can kill a component, that's ok, but the rest of the page should
> work.
> And yes I want to "make sure that no exceptions are thrown", except that's
> not so simple when you're dealing with a complex site and lots of pages,
> components and models. If I missed any exceptions, I want those to be
> handled gracefully rather than redirecting to an error page.
>
> renderAll is ONLY called on the page, all other components go through
> renderComponentTagBody to call renderNext, and both renderComponentTagBody
> and renderNext are final :(
> I tried overriding onComponentTagBody and wrapping the super invocation
> with try/catch, but then the markup gets broken because it doesn't close
> tags (i.e. advance in the markup stream?) after the exception is thrown in
> a child component, and I still get an error page :(
> renderComponent(MarkupStream) is final too, it seems that all "doors" are
> closed and locked...
>
>
> Erik van Oosten wrote:
>>
>> It won't. I think you have to dig deeper into the request rendering.
>>
>> Perhaps that overriding MarkupContainer#renderAll on all your Panels
>> that have expected exceptions will help.
>>
>> But then again, exceptions are intended for controlling the
>> non-expected. You should not use exceptions for normal page flow. In
>> other words: just make sure that no exceptions are thrown.
>>
>> Regards,
>> Erik.
>>
>>
>> aditsu wrote:
>>> Ok, but how would that let me render the rest of the page?
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20310197.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by aditsu <ad...@yahoo.com>.
Well, I'm specifically talking about unexpected runtime exceptions. I don't
want those to destroy the whole page.
They can kill a component, that's ok, but the rest of the page should work.
And yes I want to "make sure that no exceptions are thrown", except that's
not so simple when you're dealing with a complex site and lots of pages,
components and models. If I missed any exceptions, I want those to be
handled gracefully rather than redirecting to an error page.
renderAll is ONLY called on the page, all other components go through
renderComponentTagBody to call renderNext, and both renderComponentTagBody
and renderNext are final :(
I tried overriding onComponentTagBody and wrapping the super invocation with
try/catch, but then the markup gets broken because it doesn't close tags
(i.e. advance in the markup stream?) after the exception is thrown in a
child component, and I still get an error page :(
renderComponent(MarkupStream) is final too, it seems that all "doors" are
closed and locked...
Erik van Oosten wrote:
>
> It won't. I think you have to dig deeper into the request rendering.
>
> Perhaps that overriding MarkupContainer#renderAll on all your Panels
> that have expected exceptions will help.
>
> But then again, exceptions are intended for controlling the
> non-expected. You should not use exceptions for normal page flow. In
> other words: just make sure that no exceptions are thrown.
>
> Regards,
> Erik.
>
>
> aditsu wrote:
>> Ok, but how would that let me render the rest of the page?
>
>
--
View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20303184.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by Erik van Oosten <e....@grons.nl>.
It won't. I think you have to dig deeper into the request rendering.
Perhaps that overriding MarkupContainer#renderAll on all your Panels
that have expected exceptions will help.
But then again, exceptions are intended for controlling the
non-expected. You should not use exceptions for normal page flow. In
other words: just make sure that no exceptions are thrown.
Regards,
Erik.
aditsu wrote:
> Ok, but how would that let me render the rest of the page?
>
>
> Alex Objelean wrote:
>
>> There are more threads about this issue...
>>
>> In order to catch all runtime exception, you have to override default
>> RequestCycle (newRequestCycle method) in your application class and
>> override onRuntimeException method.
>>
>> Example:
>> [CODE]
>> @Override
>> public RequestCycle newRequestCycle(final Request request, final Response
>> response) {
>> return new WebRequestCycle(this, (WebRequest) request, (WebResponse)
>> response) {
>> @Override
>> public Page onRuntimeException(final Page page, final
>> RuntimeException e) {
>> //do something
>> return null;
>> }
>> }
>> }
>> [/CODE]
>>
>>
>> Alex Objelean
>>
>>
>
>
--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by aditsu <ad...@yahoo.com>.
Ok, but how would that let me render the rest of the page?
Alex Objelean wrote:
>
> There are more threads about this issue...
>
> In order to catch all runtime exception, you have to override default
> RequestCycle (newRequestCycle method) in your application class and
> override onRuntimeException method.
>
> Example:
> [CODE]
> @Override
> public RequestCycle newRequestCycle(final Request request, final Response
> response) {
> return new WebRequestCycle(this, (WebRequest) request, (WebResponse)
> response) {
> @Override
> public Page onRuntimeException(final Page page, final
> RuntimeException e) {
> //do something
> return null;
> }
> }
> }
> [/CODE]
>
>
> Alex Objelean
>
--
View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20302703.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling exceptions during render
Posted by Alex Objelean <al...@isdc.ro>.
There are more threads about this issue...
In order to catch all runtime exception, you have to override default
RequestCycle (newRequestCycle method) in your application class and override
<private Page handleRuntimeException(final Page page, final RuntimeException
e)> method.
Alex Objelean
aditsu wrote:
>
> Hi, how can I catch any exception thrown while a component is rendering,
> and either hide the component or show an error message, but allow the rest
> of the page to render?
> Modifying or replacing each such component is not an option, I need a
> general way to handle exceptions while rendering any unknown component or
> child component. Such as a getObject method from a model throwing a
> runtime exception.
>
> Adrian
>
--
View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20302542.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org