[
https://issues.apache.org/jira/browse/MYFACES-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847811#action_12847811
]
Jakob Korherr commented on MYFACES-2615:
----------------------------------------
This problem raises the following question: "where should we handle a
ConverterException?".
The javadoc of UIInput.getConvertedValue() says the following: If conversion
fails:
* Enqueue an appropriate error message by calling the addMessage() method
on the FacesContext.
* Set the valid property on this component to false
However this is weird, because the javadoc also defines the method in the
following way:
protected Object getConvertedValue(FacesContext context, Object
newSubmittedValue) throws ConverterException
But "if conversion fails" means a ConverterException and if we handle it in
getConvertedValue() as described in the javadoc, then it will never throw this
ConverterException and thus the method signature is wrong. Furthermore the
related getConvertedValue() method of Renderer has the following on the
javadoc: "if not, a ConverterException should be thrown". So shouldn't we be
consistent here? Why would the "same" method on Renderer behave different than
the one from UIInput?
Furthermore this MyFaces issue is caused, because on UIViewParameter's javadoc
of getConvertedValue() it says that we should obtain the right Renderer and
call its getConvertedValue() method (which will per definition throw a
ConverterException in the error case). The javadoc says nothing about handling
of the ConverterException here, althought it has to happen somewhere to fulfil
the spec requirements posted in this issue's description!
To stay consistent here and also to get rid of duplicate code, I think it would
be the best to have the handling of the ConverterException in
UIInput.validate(), because this is the place where getConvertedValue() is
called. Of course this is not mentioned in the spec javadoc of
UIInput.validate(). In addition to my thoughts, I did a black box test of
Mojarra and they are not handling a ConverterException in any of their
getConvertedValue() methods, but in validate(). Just as I thought and as it
makes the most sence!
Thus I'll move the code that handles ConverterExceptions from
getConvertedValue() to validate(). This will not only solve this issue, but
also prevent similar problems like this one from happening in the future.
> Conversion errors should add a FacesMessage instead of throwing a
> FacesException
> --------------------------------------------------------------------------------
>
> Key: MYFACES-2615
> URL: https://issues.apache.org/jira/browse/MYFACES-2615
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 2.0.0-beta-3
> Reporter: Jakob Korherr
> Assignee: Jakob Korherr
>
> While working on MYFACES-2614 I ran into the problem that, if a conversion
> fails, the error page is displayed with the related ConverterException. This
> should not happen, instead a FacesMessage describing the conversion error
> should be added to the FacesContext.
> See section 2.2.3 Process Validations (or also section 2.2.2. Apply Request
> Values for components with immediate set to true) of the JSF 2.0 spec:
> "Conversions and Validations that failed will have caused messages to be
> enqueued via calls to addMessage()...".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
