mark.asbach at post.rwth-aachen.de
Mon Mar 22 16:05:58 EST 2004
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
> (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
> (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.
> (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,
More information about the vtk-developers