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


Groups > comp.lang.java.programmer > #31135

ensuring unreachability

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)

Show all headers | View raw


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


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