Re: F9X twister & ADA (was: n-dim'l vectors)

["James Giles" <jamesgiles@worldnet.att.net>]

Geoff Bull wrote in message <38F41313.DAF90E74@research.canon.com.au>...
...
>>   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.

Those are (should be) in the drop-file, core file, or whatever is
generated on your system that the debugger gets to look at when
a program abnormally terminates.  If the program continues to run
*after* the error is detected, this information reflects the state
the program is in when it *does* finally terminate (ie. after
"graceful" termination).

>> 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 all parts of the program's state, those are all still present
*in* the debugging file.  You can inspect them there.

>>  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.

I think undocumented exceptions are clearly the ugliest way to
accomplish this. Any public property of a procedure which isn't
explicitly declared - by direct requirement of the language
definition - is probably a bad idea.

> And sending signals is not portable (especially to bare hw with no OS).

And, sending signals would be perfectly portable if the language
standard required them.  How bare is the hardware?  If it's all
*that* bare, it won't support I/O or exceptions either.

>Of course you have no more way of knowing which library routines might
>send signals than you do of knowing which might raise exceptions.

Why not?  The fact that a routine sends a signal can be explicitly
declared (by requirement of the language, even).  But, since the
semantics of signals isn't attached to the procedure-call chain,
there's no need to declare this fact for each procedure that calls
the one that sends the signal.  Signals are, explicitly, messages to
the process as a whole.  They are not messages to the nearest
active caller that has a handler defined.

--
J. Giles