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

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

Re: ensuring unreachability

Show key headers only | View raw

On 2/17/2015 4:54 AM, Andreas Leitgeb wrote:
> 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.

     I'd suggest deleting the final `else' and its brackets:

	case E1:
	   if (...) {
	      ...; return;
	   } else if (...) {
	      ...; throw ...;
	   }
	   ...;
	   continue;
	case E2: ...

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | 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