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=0.6 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, HK_RANDOM_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ec21c3c7cdc7ff3e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc07.POSTED!20ae255c!not-for-mail Newsgroups: comp.lang.ada From: Justin Gombos Subject: Handling invalid objects References: <1142279908.327131.230200@j52g2000cwj.googlegroups.com> User-Agent: slrn/0.9.8.1 (Linux) Message-ID: <41LSf.4126$TK2.1805@trnddc07> Date: Sat, 18 Mar 2006 03:21:36 GMT NNTP-Posting-Host: 129.44.77.228 X-Complaints-To: abuse@verizon.net X-Trace: trnddc07 1142652096 129.44.77.228 (Fri, 17 Mar 2006 22:21:36 EST) NNTP-Posting-Date: Fri, 17 Mar 2006 22:21:36 EST Xref: g2news1.google.com comp.lang.ada:3422 Date: 2006-03-18T03:21:36+00:00 List-Id: On 2006-03-18, Randy Brukardt wrote: > > You're confusing an "invalid" object with an "abnormal" > object. Accessing an abnormal one is erroneous; surely you don't > want to intentionally put that into your programs. (Remember, > "erroneous" is Ada-speak for "anything at all can happen".) The 'Valid attribute exists to be able to handle abnormal objects. Here's a concrete example. Suppose I have: type clock_type is mod 12; function hour_of_day return clock_type; If hour_of_day gets called and for whatever reason I cannot return an hour_of_day, the caller needs to know that. Exceptions are a poor choice. The quality and style guide advises against them for a good reason; exceptions are like gotos - and produce a questionable state. It would be more graceful for me to return an invalid value (like -1), so my caller can simply do a 'Valid to discover whether the operation was successful. So what are the choices? 1) Declare it as: type clock_type is mod 13; and add special handling code every time you increment or decrement the value to what you've chosen to be invalid. 2) Wrap clock_type in a record, and include a validity flag. Or loosely pass a flag back. 3) The hacker approach probably resembles something like this: invalid_hour_of_day : constant integer := -1; return_data : clock_type; if cannot_get_valid_time then for return_data'address use invalid_hour_of_day'address return return_data; end if; 4) Raise an exception. Did I miss any? They're all pretty sloppy. The second choice is probably the best one. Approach 2 on steroids: I previously worked on a team that had a generic package called something like validated_object, where you would pass in a type and it would return a private type which was internally a record with a flag and your type. Then you would call the provided "valid" function to get the validity status, a set function to set the status, and you'd have to call another function to get at the data. It was kind of a hassle to have to repackage things whenever handling something that may be invalid. It nearly doubled the number of types we handled because every type would have the validated version, but it was at least a way to pass objects that may be invalid, and it was used uniformly throughout the project (as opposed to each developer picking from any of the other approaches).