[
https://issues.apache.org/jira/browse/GROOVY-8643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17565972#comment-17565972
]
Eric Milles commented on GROOVY-8643:
-------------------------------------
FYI @CS appears to be null-safe for arrays already:
{code:groovy}
@groovy.transform.CompileStatic
void test(String[] strings) {
for (string in strings) {
println string
}
}
test((String[])null)
{code}
> Make for-in null safe for CompileStatic
> ---------------------------------------
>
> Key: GROOVY-8643
> URL: https://issues.apache.org/jira/browse/GROOVY-8643
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
> Reporter: Sergiy
> Assignee: Eric Milles
> Priority: Minor
>
> See following simple script:
> {code:java}
> import groovy.transform.CompileStatic;
> @CompileStatic
> void printList(List l){
> println "List:"
> for (Object o in l) {println o}
> println "Done"
> }
> printList(null)
> {code}
> It crashes with null pointer exception due to list being null in the for
> loop. However it works perfectly fine when CompileStatic annotation is
> removed. I believe this inconsistency is a bug as the whole point of
> introducing a new for-in construct in groovy appeared to be to make it a null
> safe construct (unlike _for (Object o: l)_ construct in java). However, when
> compiling statically, it seems to be compiled as the java iterator it
> replaces, breaking away from groovy convention without even a warning.
> Any chance to have it fixed in 3.x?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
