Re: Handling exceptions during render
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions during render
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions during render
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 <[EMAIL PROTECTED]> 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 1000 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions during render
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 1000 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions during render
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions during render
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions during render
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions during render
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions during render
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions during render
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 > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions during render
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions during render
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions during render
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]