There's a difference between throw X and throws X. One is a control flow
statement and the other is part of a method signature. throw and returndon't
necessarily have a type because they're not rval expressions. If we
wanna discuss mixing control flow statements with rval expressions, that
feels like a totally different conversation. And by the way, throwing an
exception does return control to the caller. Consider the following:
void dangerZone() throws UhOhException {
throw new UhOhException();
}
void callMe() throws UhOhException {
try {
System.out.println("Here we go...");
dangerZone();
System.out.println("We did it!");
}
finally {
System.out.println("Good or bad, we're outta here!");
}
}
On Monday, October 15, 2012 11:38:41 AM UTC-4, KWright wrote:
>
>
>
> On 15 October 2012 16:04, Casper Bang <[email protected] <javascript:>>wrote:
>
>>
>> On Monday, October 15, 2012 3:27:20 PM UTC+2, KWright wrote:
>>>
>>> Void isn't quite right though. It corresponds to "return, but with no
>>> useful information", which isn't the same thing as not returning at all.
>>
>>
>> Why the interest in modeling "not returning at all"? Isn't that mostly
>> interesting to people studying the halting problem? I'm strictly interested
>> in modelling "return with nothing" and "return with something", what else
>> is there but blocking the thread or looping indefinitely?
>>
>
> Then there's throwing an exception... Where control is NOT returned to the
> caller, but instead to the nearest matching catch{} block. From the
> perspective of the caller, a method that throws an exception has not
> returned in any way, shape or form:
>
> int someMethod(int question) {
> final int retval =
> question.equals("What is the answer?")
> ? 42
> : throw new Exception("that's not the question");
> return retval;
> }
>
>
> So what's the type of throw new Exception(...)?
> It HAS to be a subclass of int, or the definition of retval is invalid.
>
> The only possible answer is Nothing (or Bottom, or _|_ if you prefer).
> Void is an empty return, it's not a subclass of int.
>
>
>
>> A compiler seeing generic capture of Void, could allow an implicit return
>> clause (as is the case with the void keyword) and furthermore optimize
>> stack push/pop away (rather than boxing null). It seems like the issue is
>> going to come up much more, when/if closures are introduced.
>>
>> Yes, this will become a whole lot more important once folk begin using
> lambdas.
>
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/javaposse/-/CKfVvkNwfskJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
