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

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

Re: ensuring unreachability

Show all headers | View raw

On 2/18/2015 10:16 AM, Eric Sosman wrote:
> On 2/18/2015 9:40 AM, Jukka Lahtinen wrote:
>> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>>
>>>      Remember, the underlying purpose is to guard against a
>>> maintainer who might inadvertently introduce a fall-through.
>>
>> Why not just insert the break; for every case?
>> That's what it is for.
> 
>     The original code was oddly structured:
> 
>     case E1:
>         if (...) {
>            ...; return;
>         } else if (...) {
>            ...; throw ...;
>         } else {
>            ...; continue;
>         }
>     case E2:
>         ...
> 
> Inserting a `break' right before the E2 case would provoke a
> compile-time error because the statement would be unreachable.
> 
>     Andreas worries that someone might add a new alternative
> to the `if' ladder, one that doesn't `return' or `throw' or
> otherwise exit the `switch', thereby producing an unwanted
> fall-through into E2.  I think the most straightforward way to
> accomplish this is to eliminate the final `else' and brackets,
> putting the `...; continue;' at the "top level" of the case.
> 

I guess I have a different thought here.

While it's nice to try to prevent a maintainer from doing this, it's a
waste of time and effort.

You need to give the maintainer some credit, also.  A maintainer has to
be familiar enough with code that he/she can make the necessary changes.
 This means not only the syntax of the language, but the operation of
the code he/she is changing, and what it can affect in other areas of
the code.  And if he/she does make a change like the OP is concerned
about, then a code review and/or testing should catch it.

I don't think you can prevent a maintainer from making ANY mistakes, and
trying to do so in a case like this will only complicate the code,
increasing the chances for making a mistake.  And that's just the
opposite of what the OP wants.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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