Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #31135
| From | Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | ensuring unreachability |
| Date | 2015-02-17 09:54 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <slrnme63vm.uoi.avl@login.logic.tuwien.ac.at> (permalink) |
Recently I came across a snippet like this:
switch (someEnumVar) {
case E1:
if (...) {
...; return;
} else if (...) {
...; throw ...;
} else {
...; continue; // enclosing loop
}
case E2: ...
}
No fall-through is supposed to ever happen from case E1 to case E2.
All branches in "case E1" exit abnormally. But due to the complexity
it isn't overly obvious. Lateron, someone might add another else-if
branch and forget about having it exit abnormally, then it might just
happen that it does fall through, which in the given context is never
ever wanted.
What I'd like to do is set a marker just before case E2.
Obviously, I cannot place any normal statement, because the compiler
would recognize it as unreachable and barf. So, I'd like to have some
kind of anti-statement, that's ok to be unreachable, but would make the
compiler barf if it ever *became* reachable during later development.
PS:
The whole point of this question is about *compile-time* checks.
Back to comp.lang.java.programmer | Previous | Next — Next in thread | Find similar | Unroll thread
ensuring unreachability Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2015-02-17 09:54 +0000
Re: ensuring unreachability Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-02-17 08:23 -0500
Re: ensuring unreachability Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2015-02-17 13:54 -0600
Re: ensuring unreachability Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-02-17 15:51 -0500
Re: ensuring unreachability Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2015-02-18 00:40 +0000
Re: ensuring unreachability Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-02-18 08:49 -0500
Re: ensuring unreachability Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2015-02-18 16:40 +0200
Re: ensuring unreachability Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-02-18 10:16 -0500
Re: ensuring unreachability Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-18 11:02 -0500
Re: ensuring unreachability Robbie Brown <rob@example.com> - 2015-02-19 09:48 +0000
Re: ensuring unreachability Gene Wirchenko <genew@telus.net> - 2015-02-20 09:39 -0800
Re: ensuring unreachability Robbie Brown <rob@example.com> - 2015-02-19 09:50 +0000
Re: ensuring unreachability v_borchert@despammed.com (Volker Borchert) - 2015-02-19 18:20 +0000
Re: ensuring unreachability Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-19 15:24 -0500
Re: ensuring unreachability Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2015-02-19 01:28 +0000
Re: ensuring unreachability Arne Vajhøj <arne@vajhoej.dk> - 2015-02-17 18:49 -0500
Re: ensuring unreachability Martin Gregorie <martin@address-in-sig.invalid> - 2015-02-18 00:59 +0000
csiph-web