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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1094ba,86e8c626be2471ae X-Google-Attributes: gid1094ba,public X-Google-Thread: 103376,fc050a66c3b5d87d X-Google-Attributes: gid103376,public From: Geoff Bull Subject: Re: F9X twister & ADA (was: n-dim'l vectors) Date: 2000/04/12 Message-ID: <38F41313.DAF90E74@research.canon.com.au>#1/1 X-Deja-AN: 609978528 Content-Transfer-Encoding: 7bit References: <8cctts$ujr$1@nnrp1.deja.com> <38EA0440.1ECBC158@ncep.noaa.gov> <38ED4ECA.ADB698C9@sdynamix.com> <38F28A85.53809F39@sdynamix.com> <38F2C1DC.5538F9F0@research.canon.com.au> <5jJI4.297$PV.9915@bgtnsc06-news.ops.worldnet.att.net> <38F3D1D3.416B3493@research.canon.com.au> <85SI4.4008$fV.338113@bgtnsc05-news.ops.worldnet.att.net> <38F3F803.A4A56259@research.canon.com.au> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@research.canon.com.au X-Trace: cass.research.canon.com.au 955519730 10122 203.12.174.227 (12 Apr 2000 06:08:50 GMT) Organization: Canon Information Systems Research Australia Mime-Version: 1.0 NNTP-Posting-Date: 12 Apr 2000 06:08:50 GMT Newsgroups: comp.lang.fortran,comp.lang.ada Date: 2000-04-12T06:08:50+00:00 List-Id: James Giles wrote: > > Geoff Bull wrote in message <38F3F803.A4A56259@research.canon.com.au>... > ... > >Actually, in my case the point of flushing files is to *not* throw away > >the evidence of where the program was up to when it crashed. > > There's a difference between flushing files (which I didn't even > mention) and closing them They not much point going to a whole lot of trouble to explicitly close them if you're not going to bother flushinf unwritten buffers > And, > branching to a handler probably loses all of the register contents > that were present when the error arose. I'm missing something. By my definition of quit immediately you lose the contents of registers too. > I still prefer to quit *immediately*. You missed my point. Depending on the situation different users will have different needs. Quit immediately simply isn't appropriate in may situations, even if it happens to be perfect for you. > > The buffers are inside the system and not part of my process > image anyway. Systems which > throw away I/O buffer information when a process terminates > are seriously broken. What about buffered io and user defined buffering? > Like the possibility > of sending yourself a KILL signal. Well, I'll admit to once doing this in a C program. But it seems amazingly ugly compared to simply raising an exception, to get precisely the same outcome. And sending signals is not portable (especially to bare hw with no OS). Of course you have no more way of knowing which library routines might send signals than you do of knowing which might raise exceptions.