The definition of *bomb*

nickh@CS.CMU.EDU (Nick Haines) writes:
> I stand by my statement: "An SML program which successfully typechecks
> will not bomb at runtime". Such a program may include a storage leak and
> therefore (ultimately) run out of memory, but it will not core-dump except
> in this eventuality. "bomb" = "core-dump" in my vocabulary (under Unix).


This is not the definition of "bomb" that any experienced user will
generally use. A "bomb" is any failure of the program to run to its
expected completion. In fact, infinite loops are considered "bombs" (as
in: "the code bombed with an infinite loop"). Further, whether a core
dump is taken or an error message is written, or whatever, is relevant to
the approach taken by the user to isolate and correct the problem only to
the extent that each of these possibilities may leave differing qualities
of evidence as to the cause of the fault. All such faults are still
"bombs".


Let's take the "out of memory" condition as the example. If the system
just dumps core, issues a "memory allocation error" message, and halts
your code, then you've got one type of evidence available. A good,
source-level debugging tool should be able to inspect this core dump in
such a way that all information is presented to the user in the terms of
the language used. Being able to inspect the current values of various
objects in the program in the exact context of the failure is often the
very thing you need to identify the problem. (UNIX has the unfortunate
tendency to close all I/O files when it terminates a run - even those
whose contents might contain evidence of the cause. This closure loses
the file position information of *all* the files and may even lose the
*content* of temporary files.)


If the language or the user detects the fault (or intercepts the fault
when the system detects it) and "handles" the problem by issuing a
message, cleaning up and closing files, etc., then you have a different
set of information available. Often enough, the "handler" will destroy
the very information which is needed to isolate the root cause of the
problem. So it's not always desirable to use "handlers" - even though you
would not characterize this as a "bomb"!


The bottom line is that your definition of "bomb" makes an irrelevant
distinction between errors based on *how* they are reported. The user
only cares about how their cause can be isolated and corrected. Whether
the user codes an explicit test, the languages catches the fault, the
system does, or even the hardware, the important question is information
is still available about the context of the fault from which yuo can try
to identify the root cause of the problem.
--
J. Giles
[Here endeth the linguistic argument about "bomb". I'm still interested
to hear news about language design and interactions among language design,
compilers, and debuggers. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.