Who needs exceptions (was Re: Two languages, too similar, competing in the same space.)

[Alex Martelli]

"Michael Chermside" <mcherm at destiny.com> wrote in message
news:mailman.1010005623.16986.python-list at python.org...
    ...
> > btw- what do "big applications written by people with some smarts"
> > do when this global_emergency_ballast block of memory happens
> > to be the one that got corrupted?  Let me take a wild guess.
    ...
> Big applications written by people with some smarts probably don't
> corrupt memory... hey, they may even be written in <a
> href="python.org">a language</a> the doesn't allow arbitrary memory to
> be corrupted. But they still have to deal with situations like running
> out of resources.

Unfortunately, disaster cases such as corrupted memory DO happen,
and, in some kinds of applications, need to be dealt with (by a
graceful shutdown with good error reporting rather than a crash).

For example, bugs in operating systems' virtual memory subsystems
are NOT unheard of.  There's nothing a language running on top of
such an OS can really do to stop the OS from going crazy under it.

Less dramatically, any major application will have (or, similar
thing, run on top of) some components and subsystems that are
coded in assembler, C, or other low-level language, for speed and
machine-access.  The OS is just a special case of that and most
often you need other libraries as well.

So, while I WAS indeed talking about the far more common case of
resource exhaustion, the corruption case also needs to be dealt
with.

In most cases, I've found that a separate "watchdog process" that
watches over the application process[es] is the best architecture
to deal with memory-corruption and similar problems.  Not totally
foolproof, if the OS starts dirtying memory at random, of course,
but then, "ad impossibilia nemo tenetur".  The point is that the
amount of isolation that separate processes provide is a good thing
to have when you suspect one process may be destroying its own
environment.  The watchdog process can likely still be intact in
this case, and proceed to shutdown the errant application process
while logging potentially-useful data about the error.

That's not unrelated to "preallocate a tad of extra resources" --
here, the "extra resource" is a process and some memory &c for it
(the errant process might not be in a condition to fork a NEW
process for error-reporting at the time of trouble -- better do
it earlier).  But the extras need to be kept separate, "arm's
length", from the main operating capital, lest they too be
consumed in the case of a crash.  Any parallel with prudent
financial management and supervision is entirely intended; Enron
doceat...!-)


Alex