[gclist] Finalization and the insane postman bug.

[Greg Colvin]

Of course it is already the case that throwing an exception from
a C++ destructor can terminate the program.

From: Charles Fiterman <cef@geodesic.com>
> My conclusion about finalizers is that everything about running them is
> determined by the user. Priority, order, time and context. I can easily
> invent contexts where any set of requirements hold. 
> 
> What if a finalizer throws an exception? You can't tell users their
> finalizers shouldn't throw exceptions because an exception is almost by
> definition somewhat of a surprise. But having the finalizer run in a thread
> owned by the collector requires throwing the exception away. I call this
> the insane postman bug. "This letter is marked emergency, special delivery,
> do not delay. I can't deal with that right now so I'll burn the letter!" I
> can think of few bugs worse than the insane postman bug. Whatever is right
> no implementation with that bug can be right.
> 
> Adding all this to a language would be impossibly complex. Languages need
> to be simple. So what is required is a death notice. The user is informed
> by some mechanism that an object died. The death notice is an identifer
> associated with the objct not the object's address. Now priority, order,
> time and context are in the user's control. If some objects are reference
> counted they give death notices too.
> 
> At no point do objects rise from the dead to alter the bits of the living.
> That's a bug the collector promices objects will be deleted when they can
> no longer influence the order of execution. Finalizers alter the order of
> execution.
>