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,2def9aa85afa5d22
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-12-01 00:11:02 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!194.42.224.136!diablo.netcom.net.uk!netcom.net.uk!dispose.news.demon.net!news.demon.co.uk!demon!pogner.demon.co.uk!zap!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Joint Strike Fighter
Date: 01 Dec 2001 08:08:15 +0000
Organization: Pushface
Message-ID: <x7vn113qs5s.fsf@smaug.pushface.org>
References: <3BDCE159.39F6D422@adaworks.com>
 <11bf7180.0110290311.4d8d6f04@posting.google.com>
 <3BDF9C6A.C25520C5@adaworks.com>
 <3BE023AB.8F235EF5@sparc01.ftw.rsc.raytheon.com> <9rp8mo$6d8$1@nh.pace.co.uk>
 <11bf7180.0111010338.6dbc1537@posting.google.com>
 <u0cpfi8hvh7jca@corp.supernews.com> <9u5q9g$md$1@nh.pace.co.uk>
 <x7v7ks8bf0g.fsf@galadriel.frlngtn.gecm.com>
 <odNN7.43847$xS6.73869@www.newsranger.com>
 <x7v667sb4yc.fsf@galadriel.frlngtn.gecm.com>
 <9u920b$1thj$1@msunews.cl.msu.edu>
NNTP-Posting-Host: localhost
X-NNTP-Posting-Host: pogner.demon.co.uk:158.152.70.98
X-Trace: news.demon.co.uk 1007194206 nnrp-07:14585 NO-IDENT
 pogner.demon.co.uk:158.152.70.98
X-Complaints-To: abuse@demon.net
NNTP-Posting-Date: 1 Dec 2001 08:08:15 GMT
X-Newsreader: Gnus v5.7/Emacs 20.7
Xref: archiver1.google.com comp.lang.ada:17270
Date: 2001-12-01T08:08:15+00:00
List-Id: <comp.lang.ada>

"Chad R. Meiners" <crmeiners@hotmail.com> writes:

> The second path seems like it would not be useful and it would be
> annoying since it introduces an unusable exception to handle.  I
> conclude that you want to the invalidate the handle no matter what
> (since it is a result of both paths) so why do you not just silently
> ignore any errors given by the OS?

With hindsight you have a point (in this case; no doubt other examples
where by-reference is needed could be concocted!)

I'm pretty sure that the new GNAT.Sockets raises an exception on a
failed Close_Socket, and I raised your objection which was fairly
comprehensively answered; I can tell you the reasoning if you like,
mail me at <simon.j.wright@amsjv.com>, but it was to do with possible
errors in user code (closing a socket twice, for example).