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,2d2df3e9ad18fa63 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-21 14:47:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!nntp-relay.ihug.net!ihug.co.nz!west.cox.net!east.cox.net!cox.net!p01!lakeread05.POSTED!not-for-mail From: David Emery User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: ISO/IEC 14519 - Ada POSIX binding References: <3EF2F6B8.3030706@noplace.com> <3EF338C5.2010005@cogeco.ca> <87r85nqlwa.fsf@deneb.enyo.de> In-Reply-To: <87r85nqlwa.fsf@deneb.enyo.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Sat, 21 Jun 2003 17:47:06 -0400 NNTP-Posting-Host: 68.98.177.213 X-Complaints-To: abuse@cox.net X-Trace: lakeread05 1056232026 68.98.177.213 (Sat, 21 Jun 2003 17:47:06 EDT) NNTP-Posting-Date: Sat, 21 Jun 2003 17:47:06 EDT Organization: Cox Communications Xref: archiver1.google.com comp.lang.ada:39542 Date: 2003-06-21T17:47:06-04:00 List-Id: Florian Weimer wrote: > David Emery writes: > > >>If you read the rationale (one of the best parts of the document, >>IMHO), you'll see that the primary consideration for this decision >>is the fact that the set of errors for any given POSIX system call >>is NOT fixed. POSIX defines a minimum set of error conditions, >>implementations may add additional errors (and most have, particularly >>as network-based computing has expanded.) Any error handling technique >>must accomodate extension. > > > And the POSIX.5 mechanism gives us this extensibility? I don't think > so. > > If a POSIX.5 implementation raises an exception not expected by the > application, it won't be able to attribute it to the POSIX subsystem > at all (unless the application jumps through hoops and uses the Ada 95 > feature that yields the full expanded name of the exception). An implementation of POSIX.5 that raises any exception other than POSIX.POSIX_Error (or the predefined exceptions), is NON-CONFORMING (i.e. "wrong"). The error reporting model is for the POSIX call to raise POSIX.POSIX_Error. (Unlike in C...) The application program must handle this exception somehow, or be terminated. (In the latter case, the value of the POSIX process's return code is 42, "Unhandled Exception." If this number sounds familiar, you're right. See the Rationale for an explanation :-). Anyway, it's up to the application program to do The Right Thing. Good practice would be CALL_POSIX: begin posix_system_call (...); exception when POSIX.POSIX_Error => case POSIX.Error_Code is -- don't quote me on the exact -- error code values below when POSIX.No_Such_File => ... when POSIX.Bad_File_Descriptor => ... when others => ... -- represents an error the -- application cannot handle when others => ... end CALL_POSIX; So let's consider the extensibility of this approach. We add a new error code, "No_Such_Machine". This could get invoked by Open() when the pathname starts with 2 slashes, e.g. open (file => "//www.adahome.com/updates", ...); exception when POSIX.POSIX_Error => case POSIX.Error_Code is .... If we want, we can add when POSIX.No_Such_Machine => ... to the application, when we know about this new error -AND- what we should do about it. A poorly coded application can always do when others => null; -- can't handle But a better-coded application should do when others => action_for_unknown_problem; But in ALL CASES, there is a single exception that gets raised, POSIX.POSIX_Error. dave