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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc745b8412f53f25 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-29 04:20:35 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!martinkl.dialup.fu-berlin.DE!not-for-mail From: Martin Klaiber Newsgroups: comp.lang.ada Subject: Re: Error-names. Date: Sun, 29 Feb 2004 13:17:18 +0100 Organization: Freie Universitaet Berlin Sender: Martin Klaiber Message-ID: References: <404178F0.67730051@sympatico.ca> NNTP-Posting-Host: martinkl.dialup.fu-berlin.de (130.133.237.205) X-Trace: news.uni-berlin.de 1078057234 56793493 F 130.133.237.205 (10182) X-Orig-Path: not-for-mail User-Agent: tin/1.5.12-20020427 ("Sugar") (UNIX) (Linux/2.4.24 (i586)) Xref: archiver1.google.com comp.lang.ada:5943 Date: 2004-02-29T13:17:18+01:00 List-Id: David Marceau wrote: > The Ada idea from my understanding is to make it robust by separating all the > different kinds of errors and dealing with each appropriate based on its > context. The C style confuses and leaves you to wonder what the hell happened > and what exactly was the root of the cause. I'd say, this depends on the elaboration of the return values. Just returning a value /= 0 for any error is quite poor indeed. But if one returns a specific value for each kind of error, the calling C-program should be as capable as an Ada-program finding out the cause of failure. > The other thing about it is that because each case isn't handled > separately the cleanup that one is supposed to handle for every > different exception is not handled. Well, perhaps this is a misunderstanding. The example in my previous post is just an example. In reality I distinguish between more exceptions. > SUGGESTION > ----------- > don't use when others all the time. I agree. General_Error is a fallback, as I must ensure that any exception is turned into a return-value, as the calling C-programm cannot deal with the Ada-exceptions. In other parts of the library, for instance in the part where I evaluate the tax-year, I don't use 'when others' to make sure that I really handle every year for every case. > make sure when others is used it is logged somewhere. Hm, sorry, I don't understand what you mean here. > don't return integers in exception handlers. I only do it for the functions called by the C-program. > it's ok to raise another more specific exception to a higher level. > The special case > ---------------- > If you are writing a bridge that is controlled by C executable accessing an ada > shared library then yes there may be a real reason to return constants for > errors. Yes, that's what I'm doing here. The library has two interfaces, one for Ada-programs and one for C-programs. The Ada-interface is doing no exception-handling at all. All exceptions are passed to the calling Ada-program. But for the C-interface I have to ensure that the calling program can handle errors and the library is not quitting execution by itself when an error occurs. As C can't deal with Ada-exceptions, I turn them into return-values. If there is a better way to do so, I'll happily use it. > Feel free to add other special cases if you want but I'm pretty sure this is the > right direction to go instead of just porting a C mentality. I don't see that I'm porting a C mentality. I am no expert, neither in Ada nor in C, although my C is worse ;-) But AFAIK return-values are the standard way to tell a C-program that a function failed. Correct me if I'm wrong. Martin