[vtk-developers] handling failure

Michael Halle mhalle at bwh.harvard.edu
Mon Mar 22 12:02:08 EST 2004

The exception handling question is part of a larger one:
how should vtk modules handle failure?  Right now, lots
of methods seem to assume that when something goes awry,
anything goes ("print and return").  Exceptions may help
to some extent, but so might a consistent policy/methodology
on what to do when "disaster" strikes.

Memory management in this kind of situation seems to be
something of a mess right now -- several modules I've
seen don't free temporary memory lying around if they
have to abort normal processing.  I also suspect that
very few tests cover the failure code path.

One thing I always thought would be useful would be a way
to attach arbitrarily allocated heap memory to a reference
counted object.  When the object is deleted, the allocated
memory would also be freed.  Independent of exception
handling or not, it allows trivial cleanup, either
automatically by reference counting or manually by
a single explicit FreeMemory() call.

I also think a couple authoritative examples of how to handle
failure in different parts of a module would be very handy.
I don't recall ever seeing one.

Finally, perhaps the peculiarities of a pipeline-based
architecture requires some innovation -- an out-of-band
"error" event system?  I agree that an exception handling
scheme doesn't seem to address all the subtleties vtk presents.

Michael Halle
mhalle @ bwh.harvard.edu

More information about the vtk-developers mailing list