[
https://issues.apache.org/jira/browse/GROOVY-11690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11690:
-------------------------------
Description:
Consider the following script (with intentional errors since we can't multiply
strings):
{code:groovy}
@TypeChecked
def method() {
def alphabet = 'abcdefghijklmnopqrstuvwxyz0123456789'
def alphabet2 = 'abcdefghijklmnopqrstuvwxyz0123456789' *
'abcdefghijklmnopqrstuvwxyz'
def alphabet3 = 'abcdefghijklmnopqrstuvwxyz0123456789' + '' *
'abcdefghijklmnopqrstuvwxyz'
}
{code}
When reporting on the first error we don't truncate at all:
{noformat}
[Static type checking] - Cannot find matching method
java.lang.String#multiply(java.lang.String). Please check...
@ line 4, column 21.
def alphabet2 = 'abcdefghijklmnopqrstuvwxyz0123456789' *
'abcdefghijklmnopqrstuvwxyz'
^
{noformat}
For the second, since the error position is above position 40, we shrink the
output taking 30 chars before and (up to) 10 after the position where the error
occurs. It becomes quite minimal context and seems a quite drastic truncation
given we don't care how long the above non-truncated string may be:
{noformat}
[Static type checking] - Cannot find matching method
java.lang.String#multiply(java.lang.String). Please check...
@ line 5, column 62.
klmnopqrstuvwxyz0123456789' + '' * 'abcd
^
{noformat}
This kind of truncation was possibly justified when we were thinking of 80 x 24
terminals as our lowest common denominator for screen real estate, but seems a
little excessive these days.
Instead of 40, 30 and 10, I propose we use 60, 45 and 25, a very modest
increase. This then gives a little more context:
{noformat}
[Static type checking] - Cannot find matching method
java.lang.String#multiply(java.lang.String). Please check...
@ line 5, column 62.
3 = 'abcdefghijklmnopqrstuvwxyz0123456789' + '' * 'abcdefghijklmnopqrs
^
{noformat}
I am open to further discussion about what the correct numbers should be but
the above suggestion seemed to be a "no-brainer" as a little improvement.
was:
Consider the following script (with intentional errors since we can't multiply
strings):
{code:groovy}
@TypeChecked
def method() {
def alphabet = 'abcdefghijklmnopqrstuvwxyz0123456789'
def alphabet2 = 'abcdefghijklmnopqrstuvwxyz0123456789' *
'abcdefghijklmnopqrstuvwxyz'
def alphabet3 = 'abcdefghijklmnopqrstuvwxyz0123456789' + '' *
'abcdefghijklmnopqrstuvwxyz'
}
{code}
When reporting on the first error we don't truncate at all:
{noformat}
[Static type checking] - Cannot find matching method
java.lang.String#multiply(java.lang.String). Please check...
@ line 12, column 21.
def alphabet2 = 'abcdefghijklmnopqrstuvwxyz0123456789' *
'abcdefghijklmnopqrstuvwxyz'
^
{noformat}
For the second, since the error position is above position 40, we shrink the
output taking 30 chars before and (up to) 10 after the position where the error
occurs. It becomes quite minimal context and seems a quite drastic truncation
given we don't care how long the above non-truncated string may be:
{noformat}
[Static type checking] - Cannot find matching method
java.lang.String#multiply(java.lang.String). Please check...
@ line 13, column 62.
klmnopqrstuvwxyz0123456789' + '' * 'abcd
^
{noformat}
This kind of truncation was possibly justified when we were thinking of 80 x 24
terminals as our lowest common denominator for screen real estate, but seems a
little excessive these days.
Instead of 40, 30 and 10, I propose we use 60, 45 and 25, a very modest
increase. This then gives a little more context:
{noformat}
[Static type checking] - Cannot find matching method
java.lang.String#multiply(java.lang.String). Please check...
@ line 13, column 62.
3 = 'abcdefghijklmnopqrstuvwxyz0123456789' + '' * 'abcdefghijklmnopqrs
^
{noformat}
I am open to further discussion about what the correct numbers should be but
the above suggestion seemed to be a "no-brainer" as a little improvement.
> Slightly expanded error messages
> --------------------------------
>
> Key: GROOVY-11690
> URL: https://issues.apache.org/jira/browse/GROOVY-11690
> Project: Groovy
> Issue Type: Improvement
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
>
> Consider the following script (with intentional errors since we can't
> multiply strings):
> {code:groovy}
> @TypeChecked
> def method() {
> def alphabet = 'abcdefghijklmnopqrstuvwxyz0123456789'
> def alphabet2 = 'abcdefghijklmnopqrstuvwxyz0123456789' *
> 'abcdefghijklmnopqrstuvwxyz'
> def alphabet3 = 'abcdefghijklmnopqrstuvwxyz0123456789' + '' *
> 'abcdefghijklmnopqrstuvwxyz'
> }
> {code}
> When reporting on the first error we don't truncate at all:
> {noformat}
> [Static type checking] - Cannot find matching method
> java.lang.String#multiply(java.lang.String). Please check...
> @ line 4, column 21.
> def alphabet2 = 'abcdefghijklmnopqrstuvwxyz0123456789' *
> 'abcdefghijklmnopqrstuvwxyz'
> ^
> {noformat}
> For the second, since the error position is above position 40, we shrink the
> output taking 30 chars before and (up to) 10 after the position where the
> error occurs. It becomes quite minimal context and seems a quite drastic
> truncation given we don't care how long the above non-truncated string may be:
> {noformat}
> [Static type checking] - Cannot find matching method
> java.lang.String#multiply(java.lang.String). Please check...
> @ line 5, column 62.
> klmnopqrstuvwxyz0123456789' + '' * 'abcd
> ^
> {noformat}
> This kind of truncation was possibly justified when we were thinking of 80 x
> 24 terminals as our lowest common denominator for screen real estate, but
> seems a little excessive these days.
> Instead of 40, 30 and 10, I propose we use 60, 45 and 25, a very modest
> increase. This then gives a little more context:
> {noformat}
> [Static type checking] - Cannot find matching method
> java.lang.String#multiply(java.lang.String). Please check...
> @ line 5, column 62.
> 3 = 'abcdefghijklmnopqrstuvwxyz0123456789' + '' * 'abcdefghijklmnopqrs
> ^
> {noformat}
> I am open to further discussion about what the correct numbers should be but
> the above suggestion seemed to be a "no-brainer" as a little improvement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
