[vtk-developers] robustness of VTK w.r.t. disconnecting inputs

[Charl P. Botha]

Dear developers,

This has been discussed in the past, and we've all been fixing bugs
w.r.t. robustness of filters against disconnecting inputs. 
Understandably, this is often not directly tested: the normal use-case
entails that a pipeline is built and used, not that it is built, taken
apart, reconnected, re-used and so forth.

There are two points I'd like everyone to think about.

1. When the input of a filter is disconnected (i.e. it's NULL in the
ExecuteInformation or somesuch), please take care to update all the
extents in the output so that successive filters know that there is no
valid data there.  What I've done in vtkImageToImageFilter.cxx is (*I
think*) a good way (although a convenience method for this would be
handy; maybe there is one and I missed it):

     output->SetExtent(0, -1, 0, -1, 0, -1);
     output->SetWholeExtent(0, -1, 0, -1, 0, -1);
     output->SetUpdateExtent(0, -1, 0, -1, 0, -1);
     output->AllocateScalars();

This happens in the ExecuteInformation if the input is found to be NULL
but the output is non-NULL.  I added this code because pipelines were
crashing and burning.  With a previous release of VTK, load some data,
pass the data through a vtkImageThreshold followed by a
vtkImageEuclideanDistance.  Call update() on the output.  Now disconnect
the vtkImageThreshold input (i.e. SetInput(NULL)), call update on the
vtkImageEuclideanDistance and watch your app go down in flames.  I've
also put more NULL pointer checks in vtkImageEuclideanDistance.

2. Changing VTK Error handling to be exception-based would fix most of
these problems in one fell swoop.  As soon as a filter notices empty
input and throws an exception, all execution stops.  At the moment, if a
filter reports an error, the rest of the pipeline execution just
continues, causing a multitude of problems further down the pipeline.  

Thanks,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/