Groovy allows you to return null when the return type of the method is a primative and Groovy returns null when there is no expilicit return statement.

It's arguable that the correct behaviour in this case is for the null to be interpreted as false which is the default behaviour when null is treated as a Boolean

Your last sentence says it all - it must either be treated as false or it must throw a sensible exception so the user knows what the hell is going on!

So which is it going to be? I don't want this issue to disappear, I took the time to report it because the confusing error message caused me problems finding the (simple) answer.

If the method is returning back to a Java program then you are just going to get an NPE I'm afraid. Calling Groovy methods from Java can sometimes produce suprising results (e.g. you can get a checked exception thrown even though there's no throws declaration).

The method should not convert the null to false because Groovy code can quite validy look for the null value rather than false.

If the method is returning back to Groovy then you really should not get an NPE. Boxing/unboxing booleans should deal with nulls gracefully.

def boolean b(() {}

if (!b()) prinln "OK"

this currently throws an NPE and should not (I'm about to raise an issue about that)

So we can and will fix this problem when the call is made from groovy but can't and won't fix it when the call is made from Java.

I hope that clarifies the situation.

However, surely there is more we can do. Can't we produce a warning to a log when Groovy class X is called with no return value set in a method? It would seem a really bad programming style to rely on a void return type evaluating to something meaningful surely?

I think it just leaves open a source of really obscure bugs - especially when interacting with Java as you say.

I personally think that if no return value has been specified at all (the last expression evaluated to void) then I don't think it is right for the code to run without an exception. It's bad style - and how hard is it to write:

boolean someMethod()
{
callSomeVoidMethod()
false
}

Surely that is better than null --> false, as "null" assumes you know that the return type would be null and not some meta-value "void"

class MyClass implements MyInterface {
    public boolean foo() {
        println 'nothing interesting here'
    }
}

println new MyClass().foo()

with this Java interface:

public interface MyInterface {
    boolean foo();
}

yields

nothing interesting here
false

Similarly, calling from Java as follows yields the same result:

public class MyMain {
    public static void main(String[] args){
        boolean b = new MyClass().foo();
        System.out.println("b = " + b);
    }
}

Well, almost:

nothing interesting here
b = false