[
https://issues.apache.org/jira/browse/JEXL-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17358123#comment-17358123
]
Garret Wilson commented on JEXL-341:
------------------------------------
I haven't worked with this part of the code in a while, but I think my point is
that having a general exception type {{JexlException}}, I would expect its
message to be a little more explanatory. Saying just {{"bar"}} doesn't help
hardly anything at all. If there was an error evaluating the expression, I
would expect an error explaining what sort of problem there was.
Let me give an example: if you have a specific {{FileNotFoundException}}, it
might be reasonable to include only {{"bar.txt"}} in the message, indicating
which file was missing. (I still think this is not ideal; I would prefer a
separate variable indicating the file that was missing.) But imagine that
instead of a {{FileNotFoundException}} a general {{IOException}} was thrown,
and it merely contained {{"bar.txt"}} as the message. That would not be helpful
at all. I would expect it to say something like: "File not found: bar.txt". It
could be constructed by {{new IOException("File not found: "+fnfe.getMessage(),
fnfexception}}.
I'm not asking for new methods to be exposed. I'm just asking for more insight
to be given into expression evaluation errors, rather than the developer having
to rewrite the parsing logic or try to backtrack into what was happening in the
expression evaluation by drilling down into the stack trace. Just a simple
message about what happened would be useful.
In JEXL-340 in fact the message was nice: {{"undefined variable foobar"}}. That
was perfect! Imagine if it would have said simply {{"foobar"}}. That would have
been like this ticket. The problem in JEXL-340 is that it added a lot of
non-error-message implementation detail cruft
{{io.guise.mesh.JexlMexlEvaluator.evaluate}} to the error message.
So in JEXL-340 extra implementation detail cruft was added. In this ticket
JEXL-341 the error message was inadequate.
Each exception needs a way to get just an error message such as {{"undefined
variable foobar"}}. Not {{"foobar"}}. not
{{"io.guise.mesh.JexlMexlEvaluator.evaluate@1:1 undefined variable foobar"}}.
To me the distinction is clear and obvious. Maybe it's not so clear and obvious
to everyone else, sorry.
Anyway you've made your decision and closed the ticket. I was just responding
to your question and explaining the request.
The bigger problem is getting v3.2 released. Are you any closer to that? If
not, all these other tickets are meaningless if they never make it into a
release.
> Errors needs to provide more information on caught exceptions.
> --------------------------------------------------------------
>
> Key: JEXL-341
> URL: https://issues.apache.org/jira/browse/JEXL-341
> Project: Commons JEXL
> Issue Type: Improvement
> Affects Versions: 3.1
> Reporter: Garret Wilson
> Assignee: Henri Biestro
> Priority: Trivial
> Fix For: 3.2
>
>
> I have a method {{bar()}} that happens to throw a {{NullPointerException}}. A
> bug, of course. But when I use the following expression in JEXL:
> {noformat}foo.bar(){noformat}
> The {{JexlException.getMessage()}} result is:
> {noformat}io.guise.mesh.JexlMexlEvaluator.evaluate@1:… bar{noformat}
> This is too little information to be helpful (and too much irrelevant
> information— see JEXL-340). If a {{NullPointerException}} occurred during
> invocation of the method, it would be nice to know that. Otherwise the
> developer has no idea if JEXL couldn't find {{bar()}} or what exactly the
> problem was.
> Obviously this is is a low priority bug that is in no way blocking anything.
> But it sure would be helpful if it could be improved one day.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
