[
https://issues.apache.org/jira/browse/MYFACES-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063809#comment-13063809
]
Martin Kočí commented on MYFACES-3202:
--------------------------------------
MyfacesPropertyNotFoundException extends javax.el.PropertyNotFoundExpcetion and
so on? I thought about that, but in that case
1) it need 3 new exceptions MyfacesPropertyNotFoundException,
MyfacesPropertyNotWritableException, MyfacesELException
2) plus one new not specific exception for catch (Exception e) case
3) my original intent was use (Faces)Wrapper pattern and unwrap it in
ErrorPageWriter
But I agree that we should preserve previous behavior , because users expect
exception from javax.el API, I'll update it.
> Improve EL Exceptions wrapping
> ------------------------------
>
> Key: MYFACES-3202
> URL: https://issues.apache.org/jira/browse/MYFACES-3202
> Project: MyFaces Core
> Issue Type: Sub-task
> Components: General
> Reporter: Martin Kočí
> Priority: Minor
> Attachments: MYFACES-3202.patch
>
>
> From MYFACES-3053 "user should see not just a cryptic stack trace, but the EL
> expression that was being evaluated including the part of the EL expression
> that triggered the problem"
> Myfaces utilize TagValueExpression and TagValueExpressionUEL as
> TagAtrribute-aware wrappers around EL ValueExpression. But this "context" is
> only .toString() of TagAttribute and that prohibits user-frendly formatting
> of messages.
> Provide TagAttribute instance, create TagAttributeAwareExceptionWrapper that
> will hold this instance. Clients (mainly ErrorPage) can read attributes of
> TagAttribute and format it as necessary, for example "EL expression that
> triggered the problem: " + wrapper.getTagAttribute().getValue()
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
