On 8/3/11 17:05 , Mads Enevoldsen wrote:
Right, but my guess is that most of the time when you are asking for
something, you expect to get it back and then work with it. As it is, the
client code has to do null checks before continuining to use it, and if not
it might blow up quite a bit later.
For method arguments you have the @Optional to say that an argument could be
null. Wouldn't it be more symmetric if you, similarly, had to annotate that
this method is allowed to return null. So if nothing is said about the
return type it cannot be null.
Sorry, I should have been more clear: what I said is ONLY relevant to
the Qi4j API/SPI and related code. I.e. it does not apply to composites
themselves.
To be able to have assertions on return values in composites is
something I know Niclas has asked for a long time. It would be as simple
as being able to put constraints on the method rather than method
parameters, in terms of declaration. It would make things very clear,
and very Design-By-Contract-ish.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
