Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #27619 > unrolled thread

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

Back to article view | Back to comp.lang.java.programmer

Contents

  telling the javac that a method doesn't return at all... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-02-28 17:10 +0000
    Re: telling the javac that a method doesn't return at all... Lew <lewbloch@gmail.com> - 2014-02-28 16:13 -0800
      Re: telling the javac that a method doesn't return at all... Jeff Higgins <jeff@invalid.invalid> - 2014-03-01 09:12 -0500
        Re: telling the javac that a method doesn't return at all... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-03-05 13:06 +0000
    Re: telling the javac that a method doesn't return at all... Roedy Green <see_website@mindprod.com.invalid> - 2014-03-01 01:10 -0800
      Re: telling the javac that a method doesn't return at all... Jeff Higgins <jeff@invalid.invalid> - 2014-03-01 08:44 -0500
    Re: telling the javac that a method doesn't return at all... Arne Vajhøj <arne@vajhoej.dk> - 2014-03-01 22:02 -0500
      Re: telling the javac that a method doesn't return at all... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-03-05 13:31 +0000
        Re: telling the javac that a method doesn't return at all... Arne Vajhøj <arne@vajhoej.dk> - 2014-03-11 20:11 -0400
          Re: telling the javac that a method doesn't return at all... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-03-12 10:17 +0000
    Re: telling the javac that a method doesn't return at all... Mike Amling <mamling@chaff.us> - 2014-03-04 13:19 -0600
      Re: telling the javac that a method doesn't return at all... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-03-05 13:39 +0000
    Re: telling the javac that a method doesn't return at all... mike.s.schilling@gmail.com - 2014-03-04 19:30 -0800
      Re: telling the javac that a method doesn't return at all... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-03-09 14:33 +0000
    Re: telling the javac that a method doesn't return at all... Silvio <silvio@internet.com> - 2014-03-12 14:03 +0100
    Re: telling the javac that a method doesn't return at all... Michal Kleczek <michal_wytnijto@kleczek.org> - 2014-03-19 11:51 +0100
      Re: telling the javac that a method doesn't return at all... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-03-19 12:28 +0000
        Re: telling the javac that a method doesn't return at all... Michal Kleczek <michal_wytnijto@kleczek.org> - 2014-03-23 11:15 +0100

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

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.

[toc] | [next] | [standalone]

#27624

Andreas Leitgeb wrote:
> 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.

-- 
Lew 

[toc] | [prev] | [next] | [standalone]

#27640

On 02/28/2014 07:13 PM, Lew wrote:
>
> 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.

[toc] | [prev] | [next] | [standalone]

#27685

Jeff Higgins <jeff@invalid.invalid> wrote:
> On 02/28/2014 07:13 PM, Lew wrote:
>> The JLS defines exactly what reachability is.
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.

[toc] | [prev] | [next] | [standalone]

#27628

On Fri, 28 Feb 2014 17:10:57 +0000 (UTC), Andreas Leitgeb
<avl@auth.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>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.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The future has already happened, it just isn’t evenly distributed.
~ William Gibson (born: 1948-03-17 age: 65)

[toc] | [prev] | [next] | [standalone]

#27639

On 03/01/2014 04:10 AM, Roedy Green wrote:
> On Fri, 28 Feb 2014 17:10:57 +0000 (UTC), Andreas Leitgeb
> <avl@auth.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
> someone who said :
>
>> 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.

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

<http://hg.openjdk.java.net/jdk7u/jdk7u60/jdk/file/3cd7a0321a83/src/share/classes/java/lang/Shutdown.java>
<http://hg.openjdk.java.net/jdk7u/jdk7u60/jdk/file/3cd7a0321a83/src/share/classes/java/lang/ref/Finalizer.java>

and associated.

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

[toc] | [prev] | [next] | [standalone]

#27646

On 2/28/2014 12:10 PM, Andreas Leitgeb wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#27686

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 2/28/2014 12:10 PM, Andreas Leitgeb wrote:
>> 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.
>
> 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.

[toc] | [prev] | [next] | [standalone]

#27737

On 3/5/2014 8:31 AM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/28/2014 12:10 PM, Andreas Leitgeb wrote:
>>> 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.
>>
>> 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.

Could do that.

But problem still exist.

Arne

[toc] | [prev] | [next] | [standalone]

#27740

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 3/5/2014 8:31 AM, Andreas Leitgeb wrote:
>>>     	   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.
> 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.

[toc] | [prev] | [next] | [standalone]

#27682

On 2/28/14 11:10 AM, Andreas Leitgeb wrote:
>
> 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
--
QWxsZWdlZCBkaWdpdGFsIHNpZ25hdHVyZQo=

[toc] | [prev] | [next] | [standalone]

#27687

Mike Amling <mamling@chaff.us> wrote:
> On 2/28/14 11:10 AM, Andreas Leitgeb wrote:
>> 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.
>
> 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.

[toc] | [prev] | [next] | [standalone]

#27684

On Friday, February 28, 2014 9:10:57 AM UTC-8, Andreas Leitgeb wrote:
> 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())

[toc] | [prev] | [next] | [standalone]

#27703

mike.s.schilling@gmail.com <mike.s.schilling@gmail.com> wrote:
> On Friday, February 28, 2014 9:10:57 AM UTC-8, Andreas Leitgeb wrote:
>> 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,...
>
> 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. :)

[toc] | [prev] | [next] | [standalone]

#27741

On 02/28/2014 06:10 PM, Andreas Leitgeb wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#27796

Andreas Leitgeb wrote:

> 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.

--
Michal

[toc] | [prev] | [next] | [standalone]

#27797

Michal Kleczek <michal_wytnijto@kleczek.org> wrote:
> Andreas Leitgeb wrote:
>> 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();

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.

[toc] | [prev] | [next] | [standalone]

#27824

On Wed, 19 Mar 2014 12:28:29 +0000 (UTC), Andreas Leitgeb 
<avl@auth.logic.tuwien.ac.at> wrote:
> > 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.

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

-- 
Michal

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web