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

[Andrae Muys]

Michael Kelly <mkelly2002NOSPAM at earthlink.net> wrote in message news:<ork63uoftjpqujisblh4rrjq297mujf1ct at 4ax.com>...
> On Wed, 2 Jan 2002 17:50:47 +0100, "Alex Martelli" <aleax at aleax.it>
> wrote:
> 
> >Big applications written by people with some smarts start
> >with the equivalent of:
> >
> >    global_emergency_ballast = malloc(a_reasonably_big_chunk);
> >
> >The ballast is released in emergency short-of-memory situations,
> >exactly to finesse these kinds of issues.
> 
> 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.
> They get an access violation when they try to print a message
> and crap out. :-)
> 

Ok I'll bite.  What corruption?  And even if it was corrupted, how
could you get an access violation (I'm assuming SIGSEV/SIGBUS on a
unixen os) attempting to use it?  If you're recovering from a OOM
condition, you just manually allocate the necessary memory to log it
from global_emergency_balast, and ensure you use direct syscall's to
dump/sync any debugging/logging info, before free()'ing the
block/doing other resource reaping.

I'm very curious to know how you can get a SIGSEV/BUS from the above,
unless it's from the free() (which is optional, if all you want is a
clean shutdown with necessary logging/etc, you just use use the balast
in-place to do that).  Of course if free() fail's with a fault it
indicates another bug elsewhere has corrupted your malloc tables, an
orthoginal error to OOM conditions.  Specifically a "bug-free" system
needs to gracefully handle OOM, OTOH corrupted malloc tables is
symptom of a bug.

Still if I'm missed anything I'm very interested to know what it is.

Andrae Muys