telling the javac that a method doesn't return at all...

[Andreas Leitgeb]

May be a wish to the easter bunny, or I might just have missed it
so far (like some easter egg)

Suppose I have some "doCleanUpAndExit" method, that in the
end either calls System.exit() or throws some Error or custom
RuntimeException.

I'd like the compiler to *know* that this method cannot possibly
return, and that any code following it should be considered
as "unreachable" code by the compiler.

E.g., I'd have code like:

class Foo {
@DoesntReturn // tell compiler this method isn't supposed to return
public void doCleanUpAndExit() {
// compiler would barf if there was any "return"
// or possible flow to end of method.
throw new ThisIsTheEndException();
// or System.exit(); which would itself need to be thusly flagged.
}
// test1() and test2() are boolean-returning methods...
public boolean check() {
if ( ! test1() ) { // aww, it's all borked up
doCleanUpAndExit();
// any further code here would make the compiler barf
} else {
return ( test2() );
}
// compiler should know that flow won't ever arrive here,
// so there is no way that the method doesn't return a boolean..
}
}

Did I miss some annotation that already does this?
Is there anything like this already in the queue for
future Java versions?

Thanks in advance.

PS: I've already defined a "WontEverGetHereException" to throw
at certain places, where the compiler otherwise barfed about
possible non-returning exits from value returning methods, so
I'm rather asking out of curiosity for nicer solutions than
facing a real problem. Still I'd rather have it a compile-time
barf than a run-time barf if my assumptions were wrong w.r.t
possible flow...

PPS: any enlightenment about why this could be wrong-headed would
also be appreciated, except if it boils down to pointing out the
intended "exceptional" semantics of exceptions... Calling those
non-returning methods itself would only happen exceptionally.

 

[Lew]

May be a wish to the easter bunny, or I might just have missed it
so far (like some easter egg)

Suppose I have some "doCleanUpAndExit" method, that in the
end either calls System.exit() or throws some Error or custom
RuntimeException.

I'd like the compiler to *know* that this method cannot possibly
return, and that any code following it should be considered
as "unreachable" code by the compiler.

The JLS defines exactly what reachability is.

E.g., I'd have code like:
class Foo {
@DoesntReturn // tell compiler this method isn't supposed to return
public void doCleanUpAndExit() {
// compiler would barf if there was any "return"
// or possible flow to end of method.
throw new ThisIsTheEndException();
// or System.exit(); which would itself need to be thusly flagged.
}
// test1() and test2() are boolean-returning methods...

public boolean check() {
if ( ! test1() ) { // aww, it's all borked up
doCleanUpAndExit();
// any further code here would make the compiler barf
} else {
return ( test2() );
}
// compiler should know that flow won't ever arrive here,
// so there is no way that the method doesn't return a boolean..
}
}

Did I miss some annotation that already does this?
Nope.
Is there anything like this already in the queue for
future Java versions?

Not as far as I've ever seen.

Just code in accordance with the rules of reachability as they are.

 

[Roedy Green]

Did I miss some annotation that already does this?
Is there anything like this already in the queue for
future Java versions?

It does not even notice that System.exit does not return, so I would
not hold your breath for it being there already.

Perhaps the way to look at is to find a way to suppress the error
message.

 

[Jeff Higgins]

It does not even notice that System.exit does not return, so I would
not hold your breath for it being there already.

Huh. I've never had a look. Thanks.

<http://hg.openjdk.java.net/jdk7u/jd...a83/src/share/classes/java/lang/Shutdown.java>
<http://hg.openjdk.java.net/jdk7u/jd...rc/share/classes/java/lang/ref/Finalizer.java>

and associated.

 

[Jeff Higgins]

The JLS defines exactly what reachability is.

Huh. Thanks.
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.21>
I've not had a need to do a thorough parse of that section.
Thank goodness I still don't.

 

[Arne Vajhøj]

May be a wish to the easter bunny, or I might just have missed it
so far (like some easter egg)

Suppose I have some "doCleanUpAndExit" method, that in the
end either calls System.exit() or throws some Error or custom
RuntimeException.

I'd like the compiler to *know* that this method cannot possibly
return, and that any code following it should be considered
as "unreachable" code by the compiler.

E.g., I'd have code like:

class Foo {
@DoesntReturn // tell compiler this method isn't supposed to return
public void doCleanUpAndExit() {
// compiler would barf if there was any "return"
// or possible flow to end of method.
throw new ThisIsTheEndException();
// or System.exit(); which would itself need to be thusly flagged.
}
// test1() and test2() are boolean-returning methods...
public boolean check() {
if ( ! test1() ) { // aww, it's all borked up
doCleanUpAndExit();
// any further code here would make the compiler barf
} else {
return ( test2() );
}
// compiler should know that flow won't ever arrive here,
// so there is no way that the method doesn't return a boolean..
}
}

Did I miss some annotation that already does this?
Is there anything like this already in the queue for
future Java versions?

Thanks in advance.

PS: I've already defined a "WontEverGetHereException" to throw
at certain places, where the compiler otherwise barfed about
possible non-returning exits from value returning methods, so
I'm rather asking out of curiosity for nicer solutions than
facing a real problem. Still I'd rather have it a compile-time
barf than a run-time barf if my assumptions were wrong w.r.t
possible flow...

PPS: any enlightenment about why this could be wrong-headed would
also be appreciated, except if it boils down to pointing out the
intended "exceptional" semantics of exceptions... Calling those
non-returning methods itself would only happen exceptionally.

I have at a few occasions wished for the same ability.

Although I typical have needed it to avoid a compiler error.

Oversimplified example:

public int foobar(int v) {
if(v > 0) {
return v++;
} else {
System.exit(0);
return 0; // hmmmm
}
}

But to my best knowledge then no such feature exist in Java as of today.

Arne

 

[Mike Amling]

Suppose I have some "doCleanUpAndExit" method, that in the
end either calls System.exit() or throws some Error or custom
RuntimeException.

I'd like the compiler to *know* that this method cannot possibly
return, and that any code following it should be considered
as "unreachable" code by the compiler.

PS: I've already defined a "WontEverGetHereException" to throw
at certain places, where the compiler otherwise barfed about
possible non-returning exits from value returning methods, so
I'm rather asking out of curiosity for nicer solutions than
facing a real problem. Still I'd rather have it a compile-time
barf than a run-time barf if my assumptions were wrong w.r.t
possible flow...

I've wanted this, too. AFAIK, the only way is to follow each call to a
doCleanUpAndExit or similar method with something the compiler does
recognize, such as a return or a throw. It's unfortunate that this has
to be done at each call, rather than once at the method declaration.

Mike Amling

 

[mike.s.schilling]

May be a wish to the easter bunny, or I might just have missed it

so far (like some easter egg)



Suppose I have some "doCleanUpAndExit" method, that in the

end either calls System.exit() or throws some Error or custom

RuntimeException.



I'd like the compiler to *know* that this method cannot possibly

return, and that any code following it should be considered

as "unreachable" code by the compiler.



E.g., I'd have code like:



class Foo {

@DoesntReturn // tell compiler this method isn't supposed to return

public void doCleanUpAndExit() {

// compiler would barf if there was any "return"

// or possible flow to end of method.

throw new ThisIsTheEndException();

// or System.exit(); which would itself need to be thusly flagged.

}

// test1() and test2() are boolean-returning methods...

public boolean check() {

if ( ! test1() ) { // aww, it's all borked up

doCleanUpAndExit();

// any further code here would make the compiler barf

} else {

return ( test2() );

}

// compiler should know that flow won't ever arrive here,

// so there is no way that the method doesn't return a boolean..

}

}



Did I miss some annotation that already does this?

Is there anything like this already in the queue for

future Java versions?



Thanks in advance.



PS: I've already defined a "WontEverGetHereException" to throw

at certain places, where the compiler otherwise barfed about

possible non-returning exits from value returning methods, so

I'm rather asking out of curiosity for nicer solutions than

facing a real problem. Still I'd rather have it a compile-time

barf than a run-time barf if my assumptions were wrong w.r.t

possible flow...



PPS: any enlightenment about why this could be wrong-headed would

also be appreciated, except if it boils down to pointing out the

intended "exceptional" semantics of exceptions... Calling those

non-returning methods itself would only happen exceptionally.

1. Define doCleanUpAndExit() to return, say, a bool.
2. Define a constructor WontEverGetHereException(bool). (WontEverGetHereException needs to be a RuntimeException.)
3. Exit via

throw new WontEverGetHereException(doCleanUpAndExit())

 

[Andreas Leitgeb]

Yes, it (obviously) describes the "status quo".

Huh. Thanks.
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.21>
I've not had a need to do a thorough parse of that section.
Thank goodness I still don't.

I re-read it, with no new surprise popping up to me.

For my "wishlist item" the line:

"* An expression statement can complete normally iff it is reachable."

would need some elaboration that would distinguish calls to
certain-flagged void methods as "can not complete normally",
versus other expressions for which the "iff" remains valid.

 

[Andreas Leitgeb]

I have at a few occasions wished for the same ability.
Although I typical have needed it to avoid a compiler error.

Oversimplified example:
public int foobar(int v) {
if(v > 0) {
return v++;
} else {
System.exit(0);
return 0; // hmmmm

My advice here is to throw some RuntimeException or Error here.

This may be overly theoretic for System.exit(), but makes more
sense for one's custom com.example.project.StaticUtils.myExit(),
that due to some bug might fail to bail out.

But to my best knowledge then no such feature exist in Java as of today.

I feared so, but thanks for confirmation.

 

[Andreas Leitgeb]

I've wanted this, too. AFAIK, the only way is to follow each call to a
doCleanUpAndExit or similar method with something the compiler does
recognize, such as a return or a throw. It's unfortunate that this has
to be done at each call, rather than once at the method declaration.

Thanks for confirmation.

 

[Andreas Leitgeb]

1. Define doCleanUpAndExit() to return, say, a bool.
2. Define a constructor WontEverGetHereException(bool). (WontEverGetHereException needs to be a RuntimeException.)
3. Exit via
throw new WontEverGetHereException(doCleanUpAndExit())

It's rather a question of personal taste, whether one prefers
doCleanUpAndExit(); throw new WontEverGetHereException();
over
throw new WontEverGetHereException(doCleanUpAndExit());
or the other way round, but it's fine to have both to choose from.

thanks for the alternative version!

PS: I'll probably stick with the former.

 

[Arne Vajhøj]

My advice here is to throw some RuntimeException or Error here.

This may be overly theoretic for System.exit(), but makes more
sense for one's custom com.example.project.StaticUtils.myExit(),
that due to some bug might fail to bail out.

Could do that.

But problem still exist.

Arne

 

[Andreas Leitgeb]

Could do that.
But problem still exist.

Indeed it still exists. It's the problem that I started this thread for

But given the world as it is, then doing a throw is imho preferable
to doing a return.

 

[Silvio]

May be a wish to the easter bunny, or I might just have missed it
so far (like some easter egg)

Suppose I have some "doCleanUpAndExit" method, that in the
end either calls System.exit() or throws some Error or custom
RuntimeException.

I'd like the compiler to *know* that this method cannot possibly
return, and that any code following it should be considered
as "unreachable" code by the compiler.

E.g., I'd have code like:

class Foo {
@DoesntReturn // tell compiler this method isn't supposed to return
public void doCleanUpAndExit() {
// compiler would barf if there was any "return"
// or possible flow to end of method.
throw new ThisIsTheEndException();
// or System.exit(); which would itself need to be thusly flagged.
}
// test1() and test2() are boolean-returning methods...
public boolean check() {
if ( ! test1() ) { // aww, it's all borked up
doCleanUpAndExit();
// any further code here would make the compiler barf
} else {
return ( test2() );
}
// compiler should know that flow won't ever arrive here,
// so there is no way that the method doesn't return a boolean..
}
}

Did I miss some annotation that already does this?
Is there anything like this already in the queue for
future Java versions?

Thanks in advance.

PS: I've already defined a "WontEverGetHereException" to throw
at certain places, where the compiler otherwise barfed about
possible non-returning exits from value returning methods, so
I'm rather asking out of curiosity for nicer solutions than
facing a real problem. Still I'd rather have it a compile-time
barf than a run-time barf if my assumptions were wrong w.r.t
possible flow...

PPS: any enlightenment about why this could be wrong-headed would
also be appreciated, except if it boils down to pointing out the
intended "exceptional" semantics of exceptions... Calling those
non-returning methods itself would only happen exceptionally.

I do not think Java has a way of doing that but would be very interested
to learn it can be done.

Perhaps something like type Nothing in Scala, although I do not suspect
Java would solve this via the type system.

Cheers,

Silvio

 

[Michal Kleczek]

May be a wish to the easter bunny, or I might just have missed it
so far (like some easter egg)

Suppose I have some "doCleanUpAndExit" method, that in the
end either calls System.exit() or throws some Error or custom
RuntimeException.

I'd like the compiler to *know* that this method cannot possibly
return, and that any code following it should be considered
as "unreachable" code by the compiler.

You can always follow the pattern from Guava Throwables:

Error myNonReturningMethod() {
....
}

and at the call site:

throw myNonReturningMethod();

If the call site is a non-void method the compiler will complain there is no
return statement after myNonReturningMethod(). If the call site is void then
it is harmless to leave it as-is.

 

[Andreas Leitgeb]

You can always follow the pattern from Guava Throwables:
Error myNonReturningMethod() {
...
}
and at the call site:
throw myNonReturningMethod();

Now that is compact and nice

Thanks for bringing it here!

If the call site is a non-void method the compiler will complain there is no
return statement after myNonReturningMethod(). If the call site is void then
it is harmless to leave it as-is.

Not sure if I understand this line correctly, but the consequences
of throwing stuff are evident, anyway.

 

[Michal Kleczek]

Now that is compact and nice

Thanks for bringing it here!


Not sure if I understand this line correctly, but the consequences
of throwing stuff are evident, anyway.

I was imprecise. I meant the behavior of the compiler if you forget
throw keyword at the call site.