[jira] [Commented] (JEXL-341) Errors needs to provide more information on caught exceptions.

["Garret Wilson (Jira)" <ji...@apache.org>]

    [ 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)