Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Jerry Stuckle Newsgroups: comp.lang.java.programmer Subject: Re: ensuring unreachability Date: Wed, 18 Feb 2015 11:02:25 -0500 Organization: A noiseless patient Spider Lines: 57 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Injection-Date: Wed, 18 Feb 2015 16:01:46 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="f0ea22b8e90f9304762d4b6484233470"; logging-data="4961"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19lGlE7lkpP9Sb1Jf6kBLOuBzkkgYGv3kA=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: Cancel-Lock: sha1:tb9V5f8jhkyaRZMOdPO2oZA2qts= Xref: csiph.com comp.lang.java.programmer:31147 On 2/18/2015 10:16 AM, Eric Sosman wrote: > On 2/18/2015 9:40 AM, Jukka Lahtinen wrote: >> Eric Sosman 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 ==================