ti 11. lokak. 2022 klo 10.20 Martin Terra (martin.te...@koodaripalvelut.com)
kirjoitti:
>
>
> ti 11. lokak. 2022 klo 10.15 Korbinian Bachl (
> korbinian.ba...@whiskyworld.de) kirjoitti:
>
>> Hello Martin,
>>
>> thanks for the advise and I looked at it, however, I am not sure how to
>> solve my original idea here.
>>
>> I can swallow any error thats RuntimeException in onException in
>> IRequestCycleListener, but this leads not to the rest of the page magically
>> working, does it?
>>
>> I mean I can add a new RequestCycleListener with
>>
>> @Override
>> public IRequestHandler onException(RequestCycle cycle, Exception ex) {
>> ..
>>
>> if(ex instanceof RuntimeException) {
>> //swallow it
>> return null;
>> }
>>
>>
>> in it. But as soon as we got a e.g.:
>>
>> throw new RuntimeException("test");
>>
>> anywhere in the constructor/onInit of any component the error is again
>> 500, with
>> ERROR [org.apache.wicket.DefaultExceptionMapper] Unexpected error occurred
>> java.lang.RuntimeException: test
>> [...]
>>
>> behind it.
>>
>> My idea is that the component - and only that single component - that
>> fails gets "blanked" out as it is not existing while the rest of the page
>> would work regular.
>
>
> It is your application so you must know/design how to recover from the
> error. You either re-render the same page or redirect the user to a
> suitable error page.
>
Ofcourse your first course of action should be to fix the root cause of
your exception, and only for unexpected situations, you build logic to
handle the exception.
**
Martin
>
> **
> Martin
>
>>
>>
>>
>> Or did I missunderstand anything here?
>>
>> Best,
>>
>> KB
>>
>>
>>
>>
>> ----- Ursprüngliche Mail -----
>> > Von: "Martin Terra"
>> > An: "dev" <dev@wicket.apache.org>
>> > Gesendet: Montag, 10. Oktober 2022 10:03:34
>> > Betreff: Re: an idea: wicket-resilient mode?
>>
>> > It has evolved a bit:
>> >
>> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+1.5#MigrationtoWicket1.5-RequestCycle
>> >
>> > **
>> > Martin
>> >
>> > ma 10. lokak. 2022 klo 10.11 Martin Terra (
>> martin.te...@koodaripalvelut.com)
>> > kirjoitti:
>> >
>> >> Yes. You can override runtime handling yourself @
>> >> RequestCycle.onRuntimeException (at least used to be with such name)
>> >>
>> >> In production it is recommended to do so as you best see fit.
>> >>
>> >> **
>> >> Martin
>> >>
>> >> ma 10. lokak. 2022 klo 9.45 Korbinian Bachl (
>> >> korbinian.ba...@whiskyworld.de) kirjoitti:
>> >>
>> >>> Hi,
>> >>>
>> >>> we use wicket for many years now and so far it is a great framework to
>> >>> use. One thing that however seems still a bit of a problem is the way
>> >>> wicket handles (runtime) errors.
>> >>> If you look at a page then the content is often composed of 100's of
>> >>> panels and components.
>> >>> As long as every single component is working all is fine... but if
>> just 1
>> >>> of the many 100 components has any kind of runtime-errors it leads to
>> a 500
>> >>> server error.
>> >>> So I wondered: what stops us from letting wicket have a "resilient
>> mode"?
>> >>> - A mode where an runtime error in any component doesnt lead to the
>> error
>> >>> beeing done as a 500 but instead only let this single component/panel
>> >>> silently fail (by not outputting it - as if it would be
>> .visible(false))
>> >>> and do this gracefully in the background?
>> >>> While wicket doing error-logging in the background?
>> >>> All beeing done by having a setting to let wicket be
>> gracefully/resilient
>> >>> in deploymode?
>> >>>
>> >>> What do you think about this approach?
>> >>>
>> >>> Best,
>> >>>
>> >>> Korbinian
>> >>>
>> >>>
>> >>>
>>
>
