From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,203d1f2317947ef5 X-Google-Attributes: gid103376,public From: adam@irvine.com (Adam Beneschan) Subject: Re: others clause Date: 1996/09/03 Message-ID: <50hr4d$dt0@krusty.irvine.com>#1/1 X-Deja-AN: 178265960 references: <3227AAA6.67C9@ghgcorp.com> organization: /z/news/newsctl/organization newsgroups: comp.lang.ada Date: 1996-09-03T00:00:00+00:00 List-Id: In article <3227AAA6.67C9@ghgcorp.com> mbishop@ghgcorp.com writes: >Chris Sparks wrote: >> >> Why is the following not incorrect? >> >> --------------------------------------------------------------------- >> procedure T is >> >> type Enum is (A, B, C, D, E, F); >> >> T1 : Enum := Enum'First; >> T2 : Integer := 0; >> >> begin >> case T1 is >> when A => null; >> when B => null; >> when C => null; >> when D => null; >> when E => null; >> when F => null; >> when others => null; --WHY ISN'T THIS ERRONEOUS? >> end case; > >According to the Ada 95 LRM, section 5.4, each value of T1 must be >covered either explicitly by a non-other discrete choice or by others. >That is the case in the above code. The LRM does not state that if all >values are covered by non-other choices, then others is not allowed. In >fact, using others is a good idea even when all values are explicitly >covered. If you add more values to the type but forget to modify the >case statement, you can still handle the new values in the others >choice. Actually, this may be a good time to throw in one of my pet theories, developed from bitter experience: that you should NEVER (or almost never) use "when others" on an enumeration type. (I believe that others have come to the same conclusion as I have.) The reason is: "When Others" applies not only to the enumeration values that have been defined for the type but not listed elsewhere in the CASE; it also applies to all other enumeration values that you could conceivably add to the enumeration type in the future. So, if you have a really good crystal ball and you know that you will never be adding more values to the enumeration type, or that the code you write for "when others" will apply to all values that you will add in the future, it's OK to use "when others". Otherwise, don't. If you do, what will happen (this has happened to me a number of times) is that you will decide you need to extend the enumeration type with new values, and you'll look through the program to find all the cases where a value of the enumeration type is used in a CASE statement, or in a CASE clause in a record definition, to see if the code needs to be modified. But you'll miss one or two instances, and the program will compile with no problem, and it will turn out that the code in the "when others" clause was inappropriate to the new enumeration value. Now your program has a bug that you'll have to track down, assuming it's caught before you release it to the customer. On the other hand, if you avoid "when others", you'll still look through the program to find all the places where the enumeration type is used in a CASE statement, and you'll still miss one or two. But this time, the compiler won't compile the cases you've missed, since the language requires that all values of the enumeration must covered by the CASE choices. This makes it harder to create a program bug accidentally. -- Adam