[vtk-developers] Exceptions

[Mark Asbach]

Hi VTK team,

unfortunately, I'm new to this list and didn't introduce myself, so 
this is what you should know: though just shortly finished with my 
diploma in electric engineering and computer science, I'm not new to 
programming or using VTK. As a student job, I worked for the virtual 
reality center Aachen as a student researcher on the ViSTA project (VR 
toolkit including VTK support).

> OK, Since this issue has been raised before let's take a couple 
> minutes to discuss it. I have heard good and bad things about 
> exceptions but I am not personally that familiar with them. So I'd 
> like for some folks who have experience using exceptions in a large 
> project to provide some input.

The ViSTA project (not including third party parts) is approximately 
the size of VTK and we discussed exceptions a lot. At the moment, 
exceptions are only used in some subparts of the toolkit.

 From what I would expect, introducing exceptions to VTK would be 
possible and a GOOD THING in the end - BUT there are some caveats.

At first: It's a no-hassle thing to introduce try/catch blocks at 
strategic filter base-classes, thanks to the modularity of VTK. In 
addition, providing an exception base-class that contains a default 
error-handler (that calls print() for example) would help a lot. 
However, extended review of CVS checkins might turn out to be necessary 
until the community becomes accustomed to a working coding-style 
regarding exceptions.

> (Good) Using exceptions allows for effectively testing many functions 
> in one try block. This I think is a great feature. If anything ran out 
> of memory in this try block then do this... is a great feature.

That is the point.

In addition, exceptions propagate through blocks that don't know of 
errors of inner methods, while traditional error handling requires that 
all parts of a call-chain know of every possible combination of errors 
and their remedies.

> (Good) Using exceptions allows for problems to be caught and handled 
> in a deep stack such as pipeline execution without having to put in a 
> lot of extra checks. I'm not 100% sure I buy this argument. Since a 
> filter's input can be a pipeline or just a plain data object I don't 
> see how the required testing is reduced. For many cases where a 
> pipeline could produce a bad data/metadata the same bad metadata could 
> be passed to the filter directly (without a pipeline). But I will 
> agree that it could help.

But it will vanish on its way through filters that don't know of the 
error handling.

> (Bad) There is a tendency to believe that throwing an exception makes 
> everything OK. Exception based error handling seems to frequently lack 
> appropriate try / catches.

Exceptions are NOT a replacement for traditional error handling. 
Exceptions are meant to replace abort() calls or error handling in 
really severe cases.

> My concern is that with exceptions most people would just throw the 
> exception and feel their job was done. I don't think this is a 
> technical problem with exceptions but rather a bad coding practice 
> where not enough effort is put into the try catch blocks that are 
> required to make exceptions useful.

Indeed.

> (the same problem exists with not checking the return value of malloc 
> etc, so it isn't limited to exceptions, but I think exceptions 
> exacerbate the problem)

I would guess, the opposite is true - given a good exception base-class 
and good examples on error handling are provided. It will be necessary 
to make absolutely clear, that exceptions are meant for exceptional 
(and severe) failures (memory exhaustion, broken pipes, etc.) - not for 
common and statistically occurring problems.

Greetings from Aachen,

Mark