groovy
  1. groovy
  2. GROOVY-3067

Incorrect line number reporting when exception occurs inside if statement

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.6-beta-2
    • Fix Version/s: 1.6-rc-1, 1.7-beta-1
    • Component/s: bytecode
    • Labels:
      None
    • Number of attachments :
      0

      Description

      The following code

      foo = new Foo()
      
      if(foo.hello()()) {
        println "do"
        println "do"
        println "do"
        println "do"      
      }
      
      
      class Foo {
         boolean hello() {true}
      }
      

      Produces the error

      groovy.lang.MissingMethodException: No signature of method: java.lang.Boolean.call() is applicable for argument types: () values: {}
      	at Script1.run(Script1:7)
      

      As you can see the line number says its line 7 (the closing bracket of the if) which is confusing as the actual problem is on line 3. I spent ages slowing ripping out more and more code inside a larger if trying to figure out what the problem was

        Issue Links

          Activity

          blackdrag blackdrag made changes -
          Field Original Value New Value
          Assignee Jochen Theodorou [ blackdrag ]
          Component/s bytecode [ 11336 ]
          Guillaume Laforge made changes -
          Fix Version/s 1.6-rc-1 [ 14009 ]
          Fix Version/s 1.6-beta-2 [ 14261 ]
          Hide
          blackdrag blackdrag added a comment -

          as far as I can see the reason for this is that in rev 10638 the method call path did go out of ScriptBytecodeAdapter into call site caching. At that point the usual exception unwraping we do in unwarp of that class went into a direct call in the class itselft. As a result the unwrap call is nowat the very end of the method. Now as a performance optimization we have stackless exception in case the method is not found. these Exception are catched and converted in unwrap. In 1.5.x the unwrap happens before we go back in the calling bytecode. In 1.6 it is part of the calling bytecode. As a result the line number information is now wrong.

          Show
          blackdrag blackdrag added a comment - as far as I can see the reason for this is that in rev 10638 the method call path did go out of ScriptBytecodeAdapter into call site caching. At that point the usual exception unwraping we do in unwarp of that class went into a direct call in the class itselft. As a result the unwrap call is nowat the very end of the method. Now as a performance optimization we have stackless exception in case the method is not found. these Exception are catched and converted in unwrap. In 1.5.x the unwrap happens before we go back in the calling bytecode. In 1.6 it is part of the calling bytecode. As a result the line number information is now wrong.
          blackdrag blackdrag made changes -
          Link This issue relates to GROOVY-2983 [ GROOVY-2983 ]
          Hide
          Guillaume Laforge added a comment -

          Fixed too, test to be added.

          Show
          Guillaume Laforge added a comment - Fixed too, test to be added.
          Hide
          blackdrag blackdrag added a comment -

          fixed

          Show
          blackdrag blackdrag added a comment - fixed
          blackdrag blackdrag made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Fix Version/s 1.7-beta-1 [ 14014 ]

            People

            • Assignee:
              blackdrag blackdrag
              Reporter:
              Graeme Rocher
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: