[jira] [Comment Edited] (JEXL-340) JexlException message access is incomplete and reversed

["Henri Biestro (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JEXL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17258849#comment-17258849 ] 

Henri Biestro edited comment on JEXL-340 at 1/5/21, 11:45 AM:
--------------------------------------------------------------

About exceptions reporting with JEXL, it may be useful to provide a JexlInfo instance when creating the scripts; the script name is often a useful contextual info in case of errors. If no JexlInfo is provided, one is synthetized from the caller location leading to the 'io.guise.mesh.JexlMexlEvaluator.evaluate@1:1' you described.

About the getMessage/getDetail/detailedMessage: 
The super.getMessage() is the only way to access the Exception private 'detail' field so whatever detail we provide through the constructor has to be accessed this way. I'll expose getDetail() as a public method so that the raw detail information pertaining to the exception instance can be accessed. In conjunction with the actual exception class name, this should provide the flexibility you seek.
The detailedMessage() will be semantically cleaner as being the error message with its specific detail, the generic version being:
{code}
    protected String detailedMessage() {
        Class clazz = getClass();
        String name = clazz == JexlException.class
                   ? "JEXL"
                   : clazz.getSimpleName().toLowerCase();
        return name + " error : " + getDetail();
    }
{code}

And the getMessage() will retain its location/info capabilities on top of the detailedMessage() for backwards behavior compatibility.


was (Author: henrib):
About exceptions reporting with JEXL, it may be useful to provide a JexlInfo instance when creating the scripts; the script name is often a useful contextual info in case of errors. If no JexlInfo is provided, one is synthetized from the caller location leading to the 'io.guise.mesh.JexlMexlEvaluator.evaluate@1:1' you described.

About the getMessage/getDetail/detailedMessage: 
The super.getMessage() is the only way to access the Exception private 'detail' field so whatever detail we provide through the constructor has to be accessed this way. I'll expose getDetail() as a public method so that the raw detail information pertaining to the exception instance can be accessed. In conjunction with the actual exception class name, this should provide the flexibility you seek.
The detailedMessage() will be semantically cleaner as being the error message with its specific detail, the generic version being:
{code}
    protected String detailedMessage() {
        Class clazz = getClass();
        String name = clazz == JexlException.class? "JEXL" : clazz.getSimpleName().toLowerCase();
        return name + " error : " + getDetail();
    }
{code}

And the getMessage() will retain its location/info capabilities on top of the detailedMessage() for backwards behavior compatibility.

> JexlException message access is incomplete and reversed
> -------------------------------------------------------
>
>                 Key: JEXL-340
>                 URL: https://issues.apache.org/jira/browse/JEXL-340
>             Project: Commons JEXL
>          Issue Type: Improvement
>    Affects Versions: 3.1
>            Reporter: Garret Wilson
>            Assignee: Henri Biestro
>            Priority: Trivial
>             Fix For: 3.2
>
>
> I need to wrap {{JexlException}} and provide a nice error message to the user. If I have an expression using a variable {{foobar}} not present in the context, here is what {{JexlException.getMessage()}} returns:
> {quote}io.guise.mesh.JexlMexlEvaluator.evaluate@1:1 undefined variable foobar{quote}
> This is not a pretty error message. It has lots of things a user doesn't care about. I just want the real error message:
> {quote}undefined variable foobar{quote}
> But there is no way to get just that simple error message from {{JexlException}}. If you look at the source code for {{JexlException.getMessage()}}, you'll see that the "simple" message comes from {{JexlException.detailedMessage()}}.
> Unfortunately {{JexlException.detailedMessage()}} is {{protected}}—there is no way to access it from outside. Moreover the semantics of "message" and "detailed message" are reversed! The "message" should provide fewer details than the "detailed message".
> Here is what should be done:
> * {{JexlException.getMessage()}} should provide what {{detailedMessage()}} provides now. (You'll note that {{detailedMessage()}} already calls {{super.getMessage()}}; this criss-cross overriding is not the best practice. My suggestion would therefore improve and even reduce the code.)
> * A new {{JexlException.getDetailedMessage()}} should provide what {{getMessage()}} provides now.
> That would be simpler and more correct. And it would give me the simpler error message I need. If you absolutely must leave {{JexlException.getMessage()}} the way it is for backwards compatibility, at least provide a {{getSimpleMessage()}} that returns what {{detailedMessage()}} returns now. (That way you can leave {{detailedMessage()}} hidden, because it returns the _opposite_ of a detailed message.)
> I would guess that this issue of {{detailedMessage()}} returning the opposite of a "detailed message" arose out of confusion of the API docs of {{Throwable}} and {{Exception}} referring to a "detail message". But "detail message" and "detailed message" mean different things. The API docs of {{Throwable}} et. al. are referring to the message providing a detail about the {{Throwable}}. The message itself is the "detail". But when you change "detail message" to "detailed message", the "detailed" now means that the message provides additional details than a normal message. So by adding the "ed" to "detail" it changed the sense of what "detail message" originally meant (the message providing detail).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)