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

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

Re: ensuring unreachability

Show key headers only | View raw

On 18/02/15 16:02, Jerry Stuckle wrote:
> 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.

...

Sanity at last. There is no way to prevent future foul ups unless the 
original author is present and remembers his state of mind at the time 
of writing (unlikely) or is capable of prescient preemptive time travel.

Alternatively you could always *comment* your code. I know, I know it's 
a subursive idea but it does work.

... but what if someone deletes the comments (jeez) :-)

-- 
Not floundering ... just fishing

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