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.2 required=5.0 tests=BAYES_00,FROM_LOCAL_HEX, FROM_STARTS_WITH_NUMS autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c4bd2a19251049b1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> Newsgroups: comp.lang.ada Subject: Re: best practice: error handling Date: Tue, 31 May 2011 19:13:16 +0200 Message-ID: References: <0b95a2a1-6e3d-4ad1-a832-e3099a9bce37@v8g2000yqb.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: individual.net ghVE+IDdyZU/yjX3eqaPngmm+IJTcHATM+gCrbfDYZdqmRmjdI Cancel-Lock: sha1:GNGZGdriFwF45Qu4zskY7twX9Qk= User-Agent: Opera Mail/11.11 (Win32) Xref: g2news1.google.com comp.lang.ada:19595 Date: 2011-05-31T19:13:16+02:00 List-Id: milouz wrote: > I'm wondering about the best way to handle errors in Ada when calling > a function/procedure that may fails. Well, I'd say, there is no "best way". It depends on the application and the precise context. > For example, when programming on Unix systems in C, the called > functions usually return a zero or positive value on success and -1 on > failure, while setting a global variable (errno) to give some > informations about the failure. As rule of thumb I'd suggest the following: If the error should not occur under (almost) all sane circumstances (for instance, waiting on a semaphore should always succeed, unless the handle is invalid), then raise an exception. If you kind of expect the call to fail under normal conditions, a proper out-Parameter (like "Success" ;) can be added. Keep in mind, that returning some error requires a function, and until now functions can't have "out"-parameters, so returning an "error code" is only possible for those subroutines which do not need to have "out"-parameters. So for the sake of having a consistent interface, you might want to to use an "out"-parameter, regardless if the subroutine in question could otherwise be expressed as function or not. On the other hand, if you want a function to return its result, because it looks more natural, you cannot use an "Success : out Boolean", so it may be more convenient to raise an exception for errors instead of using an "out"- parameter for the result. Vinzent. -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.