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 13:59:52 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 22:57:16 +0100 Organization: Freie Universitaet Berlin Sender: Martin Klaiber Message-ID: References: <404178F0.67730051@sympatico.ca> <404243E5.376C42BB@sympatico.ca> NNTP-Posting-Host: martinkl.dialup.fu-berlin.de (130.133.237.205) X-Trace: news.uni-berlin.de 1078091991 55696588 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:5958 Date: 2004-02-29T22:57:16+01:00 List-Id: David Marceau wrote: > Martin Klaiber wrote: >> David Marceau wrote: >>> make sure when others is used it is logged somewhere. >> Hm, sorry, I don't understand what you mean here. > I just mean the reason you use "when others" in the first place is > because it is an exception you never thought about when designing > the component. This is true and it shows the dilemma. When writing the code I don't know which exceptions a real Ada-implementation might provide. But I also must ensure all exceptions are handled to give the C-program a chance to avoid a crash. So I use "when others" at last. Is there a way to find out which exceptions an implementation provides? Ok, I have the types mentioned in the ARM but the implementation could add some more. > You have to admit when this happens whatever happens in a "when > others" you have to document and figure out in what context the > situation occurred in order to go back and add more code and maybe a > new exception type to raise :) That's right. Tracking down an error is more difficult then. > The best way is to first catch it into a file in order to come back and > read about it...hence logging the "when others" exception. I think you > already understand this kind of thing but I voiced it out anyways just > in case. A perfect application should not ever get into the part of > the code inside "when others" at run-time. That said "when others" has > to exist to catch a real exception and log the real exception to enable > us programmers to analyze what the problem is later to be able to fix > it ASAP. That's my opinion. Please correct me if I'm wrong. No, you're right. But I want to avoid to implement file-I/O to keep the lib as platform- and compiler-independent as possible. Perhaps I implement a function, which allows the calling C-program to recall the last error-message. This could be used for a bug-report then. > Ada Exceptions and C Exceptions don't seem to use the same default > cleanup strategies so you have to be very careful. What do you mean by C Exceptions? Can C handle exceptions? > As you stated in a C program returning a constant value for the error is > standard "C" practice. > From what I understand, returning nothing and placing valuable information in an > "in out" parameter is more Ada95. > The valuable information I talking about is an object holding a structure of a > bunch of structures. Ok, but complex types might give problems with the representation. I also wanted to use records/structs for the interface first, instead of the many set- and get-procedures/-functions. But people told me that a C-program compiled with a different compiler than the compiler used for the Ada-lib doesn't necessarily represent the types in the same way. So I only use the C-types "int" and "long" now. This makes it more simple and hopefully more robust. > Also notice one line for the opening brace/parentheses and another line for > closing brace/parentheses. Call me crazy but I think it is most legible this > way. It also helps you do focus on one problem at a time for each line. I > follow the same style for if statements and everything else. Sure it takes a > bit more time but in the long run it's better in my humble opinion. It think this is very individual preferences and cannot be answered generally. So I wouldn't puzzle myself with it. Preferences also change with time. I use more underscores now. Before I found the code without underscores more legible, now it's the other way round. Martin