Hi Bas,
> The thread local is probably to store the component + exception, so
the listener can access it?
yes, it allows the exception handler to identify the when and where of a
problem. A redirect to a full page render is possible, after
removing/replacing the offending component.
Hi Sven,
Thank you for explaining in detail, it helps a lot :-)
Part of your steps I have already implemented, but I never thought about
marking optional components or relying on Behavior#onException.
Since some components can be replaced in AJAX request, I guess you add an
exception-catching
Hi Bas,
>E.g. do you handle exceptions within the model itself, or with a
RequestCycleListener?
a requestCycleListener is my preferred solution:
- I've used Spring interceptors to wrap all exceptions from the service
layer for easier identification of the origin of the problem
- check the
Hi Sven,
Thank you for your reply.
On catching failure “when it happens”: can you explain what that looks like
for you?
E.g. do you handle exceptions within the model itself, or with a
RequestCycleListener?
I think the tricky part is handling exceptions thrown by models, unless I
guard every
Hi Bas,
in my experience is is very hard to check every possible failure upfront
in preconditions (whether from page or models). There's always a
corner-case waiting to hunt you.
Therefore I prefer using option 1: catch the failure when it happens.
Worked fine for me (most of the time), but
