Details
-
Type:
Sub-task
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.1-beta-3
-
Fix Version/s: None
-
Component/s: bytecode
-
Labels:None
Description
Currently, a method invocation that returns no value evaluates to null. But sometimes it's important to know whether the method actually returned a value or not (e.g. DSLs come to mind). Therefore I propose that method invocations that return no value evaluate to a known constant (e.g. Constants.NO_RETURN_VALUE) instead of null. Apart from making the language more consistent, this would fit in nicely with Groovy's dynamic style, where the return type of a method is generally not known at compile time, and a method might only sometimes return a value.
Related discussions on the mailing list:
http://www.nabble.com/Void-the-same-as-null--tf3535287.html#a9867884
http://www.nabble.com/Ways-to-differentiate-between-methods-that-return-nothing%2C-and-methods-that-return-null-tf4574659.html#a13057848
Given the premise, that for some methods it's important to know whether a value was returned or not, should the method not take responsibility and simply return something (specific) or nothing (null)?
Why should the langauge be elaborated to accommodate inattentiveness or carelessnes on the part of the programmer?
Randall Schulz