From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!pBWEO6hi52oGFheO/GY5ag.user.gioia.aioe.org.POSTED!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Ada and "early return" - opinion/practice question Date: Tue, 16 Mar 2021 02:13:54 -0700 Organization: Aioe.org NNTP Server Message-ID: <865z1rea0d.fsf@stephe-leake.org> References: <38356aa9-b8b0-4e0b-a490-99e7b239d0b1n@googlegroups.com> <86eegge32o.fsf@stephe-leake.org> NNTP-Posting-Host: pBWEO6hi52oGFheO/GY5ag.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (windows-nt) Cancel-Lock: sha1:+P8C0jZikn54b/zcmTEz0SUDfAA= X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader02.eternal-september.org comp.lang.ada:61550 List-Id: John McCabe <"john@nospam.mccabe.org.uk"> writes: > On 15/03/2021 17:31, Stephen Leake wrote: >>John McCabe writes: >> > <..snip..> > >>> For example, you have a C++ function (pseudo code sort of thing): >>> >>> fn() >>> { >>> if () >>> { >>> return ; >>> } >>> >>> if () >>> { >>> return ; >>> } >>> >>> if () >>> { >>> return ; >>> } >>> >>> // Only get here if everything's good... >>> >>> return ; >>> } >>> > > > >>I would tend to use an exception for "something bad", but that depends >>on the overall design. > > Thinking back on this point, would you do it a style where you try to do > what needs to be done then handle the exception when it fails? For example, > in this style > > begin > > exception > when blah blah > end No, your example fn returns a status code to the caller for "something bad", so the Ada fn should raise an exception, and the caller (or some function up the call chain) should handle it. > Or do you mean, rather than return when the undesirable condition occurs, do > something like: > > if then > raise > end if; Yes, but with helpful info in the exception message: raise with "explanation"; For example, if the problem is that some number is out of bounds, the "explanation" should include both the number and the bounds. And if the bounds can be adjusted by a user option, the option name. The most frustrating error message ever is from Windows, when a program is missing some DLL or other file; the error message says: the file cannot be found. _Which_ file???!!! the program knows exactly what file name it is looking for, and what directories it is looking in; why isn't it telling me? Sigh. I often spend a lot of effort to improve error messages; they help a lot when debugging, especially a few years later. Sometimes I would like to pass data with the exception, as other languages support, but not often. -- -- Stephe