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!news2.google.com!atl-c05.usenetserver.com!news.usenetserver.com!cycny01.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc02.POSTED!20ae255c!not-for-mail Newsgroups: comp.lang.ada From: Justin Gombos Subject: Re: Handling invalid objects References: <1142279908.327131.230200@j52g2000cwj.googlegroups.com> <41LSf.4126$TK2.1805@trnddc07> <7LOSf.34253$oL.29742@attbi_s71> User-Agent: slrn/0.9.8.1 (Linux) Message-ID: Date: Wed, 22 Mar 2006 02:06:37 GMT NNTP-Posting-Host: 129.44.77.228 X-Complaints-To: abuse@verizon.net X-Trace: trnddc02 1142993197 129.44.77.228 (Tue, 21 Mar 2006 21:06:37 EST) NNTP-Posting-Date: Tue, 21 Mar 2006 21:06:37 EST Xref: g2news1.google.com comp.lang.ada:3540 Date: 2006-03-22T02:06:37+00:00 List-Id: On 2006-03-20, Randy Brukardt wrote: > > You should have; such a coding standard is brain-damaged. Unless > there is a total ban on exceptions (as in SPARK -- and I disagree > with SPARK on that), there is no good reason to avoid > exceptions. You would avoid exceptions for the same reasons you might avoid using a goto statement. An exception is only a specific type of goto statement - and gotos are not exactly state of the art. > Indeed, my view is exceptions and exception handling were one of the > primary leaps forward for Ada over its sibling languages Pascal and > Modula. Using exceptions in cases like this allow the writer of the > routine to be sure that the error is not ignored, causing cascading > problems later - and ensure that the error is localized if it is > made. Quite the opposit. I see neglected potentially raisable exceptions routinely. They are particularly easy to ignore - and in fact often difficult for untrained users to even know they're using something that would raise an exception. This makes exceptions the worst kind of goto. You can command a jump without even providing a place to go. It is the alternatives that forces the user of an API to address problem cases. In the case of functions, wrapping return data in a varient record is not something that can be ignored. Ignoring an "out" object on a procedure requires cases of neglect to be deliberate. >> Exception raising and handling is often viewed as writing code that >> will never execute. Predefined exceptions must be handled when >> there is an expectation they will be raised, but their usefullness >> stops there. Beyond that, it's like writing erroneous code on >> purpose. > > Yikes! I hope you never work for me! Rightly so. Bringing me into a sloppy environment with undisciplined Ada programmers and a mess of spaghetti code could quickly create a tough environment - and a particularly hostile one if I'm also forced to do poor quality work myself. I would not be a team player in that case, and you should not hire me. > I think returning an invalid value on purpose is like writing > erroneous code on purpose. That's because you're trusting the caller > to do the right thing and check something; It's exceptions that require trust. In fact, you can ignore an exception accidentally. Return a known and documented bad value, or varient record, and the user must not incompetent to miss it. Well developed Adaists can pull off using exceptions conservatively (just like they can gotos), with minimal benefit. However, you also can't ignore the fact that most Ada developers are incompetent, and will write code that doesn't execute, create exceptions for situations that are not exceptional, and fail to handle exceptions. I've seen new developers use exceptions to handle normal operating conditions. And you can't get away with only letting the advanced users write exceptions, because their code will interface with that of a non-proficient programmer. There are too many gotchas to justify them in light of better alternatives. -- PM instructions: do a C4esar Ciph3r on my address; retain punctuation.