[ 
https://issues.apache.org/jira/browse/GROOVY-12667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137432#comment-18137432
 ] 

ASF GitHub Bot commented on GROOVY-12667:
-----------------------------------------

codeconsole opened a new pull request, #3188:
URL: https://github.com/apache/groovy/pull/3188

   An implicit-this method call from a closure whose resolve strategy is 
`DELEGATE_FIRST` and whose delegate is null is sent to `NullObject`. Instead of 
reaching the owner, it throws `NullPointerException: Cannot invoke method foo() 
on null object`:
   
   ```groovy
   class Owner {
       def foo() { 'owner' }
       def test() {
           def c = { -> foo() }
           c.resolveStrategy = Closure.DELEGATE_FIRST
           c.delegate = null
           c()
       }
   }
   assert new Owner().test() == 'owner' // NPE since 4.0.0
   ```
   
   `OWNER_FIRST` with a null owner (the delegate is never tried) and a 
dehydrated closure behave the same way. A method neither candidate has throws 
the NPE instead of `MissingMethodException`. Since GROOVY-11858, `toString()` 
and `is(x)` in such a closure run against `NullObject`. Groovy 3 skipped a null 
delegate or owner, and `Closure.getProperty` still does. Seen in 4.0.33, 5.0.8 
and 6.0.0.
   
   GROOVY-7232 dropped the `instanceof GroovyObject` check from the 
`DELEGATE_FIRST` and `OWNER_FIRST` branches of `ClosureMetaClass.invokeMethod` 
so that non-Groovy delegates work, and that also let null through. Those 
branches now require a non-null delegate or owner before trying it. The 
`*_ONLY` branches already exclude null.
   
   This and #3185 (GROOVY-12664) change different lines of 
`ClosureMetaClass.invokeMethod`; both append tests to `ClosureDelegationTest`.
   
   ## Tests
   
   `ClosureDelegationTest` gains `testDelegateFirstWithNullDelegate` (owner 
method, `toString()` and `is`), 
`testDelegateFirstWithNullDelegateStaticContext`, 
`testDelegateFirstWithNullDelegateTypeChecked`, `testOwnerFirstWithNullOwner`, 
`testMissingMethodWithNullDelegate` and `testDehydratedClosureMissingMethod`. 
All six fail without the change. `groovy.lang.*Closure*`, `groovy.*Closure*`, 
`gls.invocation.*`, `org.codehaus.groovy.runtime.*`, `groovy.transform.stc.*`, 
`org.codehaus.groovy.classgen.asm.sc.*` and `groovy.ThisAndSuperTest` pass. The 
Checkstyle and CodeNarc gates pass.
   




> Implicit-this call in a DELEGATE_FIRST closure with a null delegate throws 
> NullPointerException instead of calling the owner
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-12667
>                 URL: https://issues.apache.org/jira/browse/GROOVY-12667
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 4.0.33, 5.0.8, 7.0.0-alpha-1, 6.0.0
>            Reporter: Scott Murphy Heiberg
>            Priority: Major
>
> {code:groovy}
> class Owner {
>     def foo() { 'owner' }
>     def test() {
>         def c = { -> foo() }
>         c.resolveStrategy = Closure.DELEGATE_FIRST
>         c.delegate = null
>         c()
>     }
> }
> assert new Owner().test() == 'owner'
> {code}
> *Actual:* {{java.lang.NullPointerException: Cannot invoke method foo() on 
> null object}}. The same happens for OWNER_FIRST with a null owner (the 
> delegate is never tried), for a dehydrated closure, and for a method that 
> neither candidate has (NPE instead of MissingMethodException). Since 
> GROOVY-11858, {{toString()}} in such a closure returns "null" and 
> {{is(null)}} returns true, because they run against NullObject.
> *Expected:* a null delegate (or owner) is skipped and the other candidate 
> answers, as in Groovy 3 and as property access ({{Closure.getProperty}}) 
> still does. When neither answers, a MissingMethodException is thrown.
> Cause: GROOVY-7232 removed the {{instanceof GroovyObject}} check from the 
> DELEGATE_FIRST and OWNER_FIRST branches of {{ClosureMetaClass.invokeMethod}}, 
> which also let a null delegate or owner through to 
> {{InvokerHelper.invokeMethod(null, ...)}}.
> Verified: 4.0.33, 5.0.8, 6.0.0 and master affected; 3.0.25 and 2.4.15 not 
> affected.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to