Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Mike Amling Newsgroups: comp.lang.java.programmer Subject: Re: telling the javac that a method doesn't return at all... Date: Tue, 04 Mar 2014 13:19:49 -0600 Lines: 26 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net djr/fL6awARKwThTJlSeOwXVBo9ZFzTjn2o1NcmkCD9JnFYNZj Cancel-Lock: sha1:Bib8lfYmS2IzT1ewQEVmhwUULg4= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer: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=