Details
-
Sub-task
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
None
-
None
-
None
Description
Requirement: "user should see not just a cryptic stack trace, but also the component that triggered the problem"
Problem in current code is that first exception breaks current phase and exception in queued without component info.
I think that every lifecycle method (processDecodes, processValidator etc.) should try catch every exception and publish it for later processing with exception handler.
Spec does not says it directly but we can find:
"The exception must not be re-thrown. This enables tree traversal to continue for this lifecycle phase, as in all the other lifecycle phases" from UIInput.updateModel
"ExceptionHandler is the central point for handling unexpected Exceptions that are thrown during the Faces lifecycle" from ExceptionHandler javadoc
process* method can silently "do nothing" : UIInput.updateModel does it already.
Publishing event allows handle multiple problem at once: consider buggy validators/converters -> create more than one exception in queue and coder can see them at once.
The main parameter of ExceptionQueuedContext is UIComponent and the best place where component is always known is component itself.