Re: Constructor Bombs without Assignment to "this"

[Michael McClary <michael>]

Fine stuff.

> Two mooses:
> 
> 1) How do we combine the above scheme with the "become" technique in
> my previous message?  I simply haven't thought about it.

I'll assume the worst case here:  that flock pack/unpack end up happening
during the "become".

The semantics of a construction failure is that the object (and the related
structures it creates) doesn't exist.  The logical extension to "become" is
that the "become" didn't happen.  The object (and its dependents) are
unchanged (or at least in a valid state), and the Problem tells you what
went wrong.  (If you can fix the problem, you can then try again.)

Per my previous letter, we can gurarntee no allocation failures (because
there's the right amount of memory) on Stub/Shepherd conversions.

On the Shepherd->Stub conversion, non-allocation failures should all be
similarly hand-wavable-away.  The only ones I can think of are "Can't pack
the flock" (if that's part of the "become" process) and destructor failure
in the shepherd or the sheep.  But both are should-never-happens.

On Stub->Shepherd conversion, failures are more likely, since much memory
must be allocated for the sheep and for more stubs.  But if there is a
constructor failure, the situation can be resolved by:
 - Destroying the partially-constructed Shepherd (and thus its partial flock).
 - Reconstructing the Stub.
 - Propagating the Problem outward in the normal fashion.

Moose 1 is dead.

	michael