[jira] [Commented] (JEXL-341) Errors needs to provide more information on caught exceptions.
[
https://issues.apache.org/jira/browse/JEXL-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17358572#comment-17358572
]
Henri Biestro commented on JEXL-341:
I must be missing the obvious but JexlException is subclassed in
JexlException.{Variable,Property,Method,Operator,Parsing,Feature,Ambiguous}
which are the actual instances thrown. The class names are mostly self
explanatory and the actual messages reflect those names.
And again, if you were to provide a JexlInfo when creating the script, you
wouldn't have the default context (the class name/method) in your exception
message but yours (as in 'Validation for login' or whatever you see fit).
And 3.2 has just been released.
> 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)
[jira] [Commented] (JEXL-341) Errors needs to provide more information on caught exceptions.
[
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)
[jira] [Commented] (JEXL-341) Errors needs to provide more information on caught exceptions.
[
https://issues.apache.org/jira/browse/JEXL-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277450#comment-17277450
]
Henri Biestro commented on JEXL-341:
Same as JEXL-340, have you made any progress trying to use the code as it
stands ? I'm a bit confused at how much change you expect or need. Any public
method exposed from JEXL is yet another one to maintain forever so we must be
absolutely convinced of the actual value this would bring. I kinda expect GUISE
to handle its own errors with its own contextualised messages so you'll need
error handling on your end; adding the 3 lines of logic on your required end
(per JEXL-340 comment) seems a reasonable trade-off, doesn't it ?
> 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
>
> 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)
[jira] [Commented] (JEXL-341) Errors needs to provide more information on caught exceptions.
[
https://issues.apache.org/jira/browse/JEXL-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259353#comment-17259353
]
Garret Wilson commented on JEXL-341:
The point of all this (and JEXL-340) is that I'm creating an entire templating
framework from the ground up in
[GUISE-170|https://globalmentor.atlassian.net/browse/GUISE-170], currently
using embedded JEXL as the foundation of the expression language. Users (who
may be web savvy but not necessarily Java savvy) will add their own expressions
in the HTML. I need a way to nicely tell the user when something went wrong
with their expression. Even if the problem in the method invocation happened
not to be their fault (in the case of a {{NullPointerException}} it would have
been my fault, that of the developer), it would be helpful to give them some
sort of useful error message, be it "Null reference error in bar()" or even
"unexpected error in bar()". If they just see "bar", they will be very confused.
> 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
>
> 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)
[jira] [Commented] (JEXL-341) Errors needs to provide more information on caught exceptions.
[
https://issues.apache.org/jira/browse/JEXL-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259351#comment-17259351
]
Garret Wilson commented on JEXL-341:
What I'm getting at is that somewhere the JEXL code (I haven't investigated;
I'm guessing from experience) is wrapping the method invocation with some sort
of {{try\{…\} catch(Throwable t)}} just so it can be sure that the whole thing
doesn't blow up when the method implementation (in this case, my code) has a
bad bug.
That's reasonable; I'm just suggesting that it would be helpful if the detail
message at least gave some indication of what went wrong. Just saying "bar"
isn't really helpful. Ideally you would do something like this:
{code:java}
try {
invokeBar();
} catch(JexlException je) {
throw je;
} catch(NullPointerExeption npe) {
throw new JexlException("Null reference when invoking `bar`", npe);
} catch(Throwable t) {
throw new JexlException("Unexpected error when invoking `bar`:
"+t.getMessage(), t);
//I would guess you are doing this currently: throw new
JexlException("`bar`", t);
}
{code}
Even just adding the "unexpected error" part would be helpful, because later
Java versions are going to add more information to the {{NullPointerException}}
message anyway:
{code:java}
} catch(Throwable t) {
throw new JexlException("Unexpected error when invoking `bar`:
"+t.getMessage(), t);
}
{code}
We don't need the whole {{Throwable.toString()}} in the message. Just the
{{Throwable.message()}} (if it isn't {{null}}). In fact any little message
saying "unexpected error invoking bar()" would be really more helpful than
simply "bar".
It should be an extremely simple change that will bring loads of help.
Again, this is a tiny, trivial suggestion, but it would be helpful.
> 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
>
> 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)
[jira] [Commented] (JEXL-341) Errors needs to provide more information on caught exceptions.
[
https://issues.apache.org/jira/browse/JEXL-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17258935#comment-17258935
]
Henri Biestro commented on JEXL-341:
A JexlException instance does have a cause (getCause()) which is the NPE thrown
by bar() including its stacktrace. In most (if not all) cases, the cause is
either an ArithmeticException thrown by a JexlArithmetic operator or a
user-code triggered exception.
Using a JexlInfo instance during script creation that provides location
details, the actual class (JexlException) and the cause, it seems all required
information is available.
Depending on the user population and platform usage, the amount of information
to display vs what should be logged is an integration choice. Not sure what the
generic improvement should be...
> 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
>Priority: Trivial
>
> 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)
