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.
Or did I missunderstand anything here?
Best,
KB
----- Ursprüngliche Mail -----
> Von: "Martin Terra"
> An: "dev" <[email protected]>
> 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 ([email protected])
> 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 (
>> [email protected]) 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
>>>
>>>
>>>
