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,d8a4797a79f9c90f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-27 09:32:54 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!cyclone.bc.net!news.uunet.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Message-ID: <3ED38FA6.5050002@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: I/O - exception handling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 27 May 2003 12:17:42 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1054052262 198.96.223.163 (Tue, 27 May 2003 12:17:42 EDT) NNTP-Posting-Date: Tue, 27 May 2003 12:17:42 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:37846 Date: 2003-05-27T12:17:42-04:00 List-Id: Hyman Rosen wrote: > The main problem is that when you get an error on closing a > file, there's no recovery possible short of trying to recreate > its contents somehow and somewhere. It's more like a hardware > error than anything else. But it is _still_ necessary to pay attention to this case. Using fclose() in C (which GNAT calls upon), is a good example. If the underlying fclose() fails this could represent a variety of serious program flaws and/or media defects: - If there has been no prior Flush (or fflush in C), then this could be a "write error" for buffered data - this could have serious consequences. - If you have closed the underlying file descriptor that the File_Type (or FILE in C) is using, then unwritten data is also not getting out (In Ada this can be done by using POSIX.IO.Close(File_Descriptor) somewhere else in the code). Basically, if close fails, this indicates that you most likely have a serious code flaw, or at minimum, that you have a hardware media problem (or possibly some other corruption problem). IMO, the worst thing you can do is ignore the problem, unless for example you are _expecting_ failures. Maybe this is stating the obvious, but an example of this might be where you might do this in C, where you want to be sure that any files that were opened by the parent process, are now closed: if ( !(PID = fork()) ) { /* In child process */ for ( fd = 0; x < NOFILE; ++x ) close(fd); /* Ignore errors: close all files */ I think raising exceptions in close makes sense, because I have not found too many programs that actually check that close succeeds. Those same programs do not call fflush prior to the close either (if they do, they don't check the result). If this were an editor for example, I would be extremely annoyed that the last 4K of my code got truncated because the close()->fflush() call failed because the file system returned ENOSPC! I would expect that the editor would then either keep my original source file somewhere else or that I get another chance to save it, somewhere else. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg