[
https://issues.apache.org/jira/browse/JEXL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated JEXL-340:
-------------------------------
Description:
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).
was:
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.
It's not apparent to me why the current roundabout implementation was used to
begin with, or what benefit it brings.
> 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
> Priority: Trivial
>
> 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)
