Oh, you mean like the calling conventions on the IBM Mainframe where a dump
produces a trace back up the call chain to the calling program(s)? Not to
mention the trace stack kept within the OS itself for problem solving
(including system calls or SVC's as we call them on the mainframe). And
| Oh, you mean like the calling conventions on the IBM Mainframe where a dump
| produces a trace back up the call chain to the calling program(s)? Not to
| mention the trace stack kept within the OS itself for problem solving
| (including system calls or SVC's as we call them on the mainframe).
I can't say enough good things about this interview:
Conversation with Bruce Lindsay
Design For Failure
http://www.acmqueue.org/modules.php?name=Contentpa=showpagepid=233
snip
BL: There are two classes of detection. One is that I looked at my own guts and
they didnt look right, and so I say
Pascal Meunier [EMAIL PROTECTED] wrote:
Tim Hollebeek [EMAIL PROTECTED] wrote:
(2) in many languages, you can't retry or resume the faulting code.
Exceptions are really far less useful in this case.
See above. (Yes, Ruby supports retrying).
Bjorn Stroustrup discusses retrying exceptions
On Fri, 1 Sep 2006, Jonathan Leffler wrote:
| Pascal Meunier [EMAIL PROTECTED] wrote:
| Tim Hollebeek [EMAIL PROTECTED] wrote:
| (2) in many languages, you can't retry or resume the faulting code.
| Exceptions are really far less useful in this case.
|
| See above. (Yes, Ruby supports