The Philosophy of Nothing

[Neal Gafter]

On Mon, Nov 30, 2009 at 10:31 PM, Paul Benedict <pbenedict at apache.org>wrote:

>  2) Outside of the whole closure conversation, can java.lang.Nothing be
> used? And is there value in it? For example:
>
>  class Test {
>>  public Nothing throw_it() {
>>    throw new AssertionError();
>>  }
>> }
>>
>
> Yes, but the most important use cases arise with closures.
>
>
>
> Java existed all this time without caring whether methods complete or not.
> Neither Java reflection, dynamic language support, or JSR-292 has had a
> pressing desire to know this. Are we sure this is a good advancement in the
> language design? Aside from closure support, what is the value in saying a
> method returns Nothing?
>

I don't think it is a critical feature in a language that doesn't have
closures.

  3) In regards to byte-code manipulation, what would happen at runtime if a
>> class transformer takes the body of method that cannot return normally
>> ("returns" java.lang.Nothing) and actually returns? The opposite case must
>> be considered too. Would a JVM error be thrown?
>>
>
> Yes.  It would be a NullPointerException at the call site (that's the only
> value the verifier would let be returned from a Nothing-returning method).
> The opposite case (failing to return from a method) isn't an issue.
>
>
> I don't think NPE is very descript in this situation or useful in helping
> debugging. I think the error goes beyond bogus pointers and into something
> more deep. Can you consider a new Exception for this?
>

Given that null is not a valid value for Nothing, and triggering the
"problem" requires working under the covers, I don't see much value in
adding to the platform another exception type.  I did have to diagnose this
kind of problem while writing the closures implementation, and I found it
easy with the null pointer exception.  I'd be interested to hear any
experience to the contrary.

Cheers,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091130/51bb434b/attachment-0001.html