[
https://issues.apache.org/jira/browse/JEXL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17258849#comment-17258849
]
Henri Biestro commented on JEXL-340:
------------------------------------
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)
