[Insight-developers] My Dashboard Compile Errors and assert()'s

[Stephen Aylward]

Dang - I was hoping to not have to go into more detail...

> When an algorithm is dependant of the content of
> the manipulated data, it is very difficult to test all the cases. Keeping
> the asserts in the code can highlight a problem with new data, which would
> have be very difficult to found without them.

This is exactly when we should use an exception instead of an abort.

Keep in mind that we have three types of people involved in this scenario:

1) "ITK Developers" (aka Luis wanna-be's :) ).   We have access to ITK
code, we don't mind looking at ITK code, and we are somewhat accepting
of its flaws.

2) "ITK Users" are people who don't read this list, who download ITK
from the web, and who expect ITK to be perfect :)    They should never
have to look inside ITK .txx/.cxx files...and they really should never
have to modify ITK's .txx/.cxx files.  They want to write programs,
using ITK, that can be given to others.

3) "Application Users" are people who use the programs written by ITK
Users.   They want the programs to be perfect :)    But, in
particular, they really don't want the programs to crash.

The existence of ITK Users between ITK Developers and Application
Users is exactly why we need to use exceptions instead of asserts.

ITK Users need to be able to catch an exception that is informative
and that help them use ITK code as the ITK Developers intended.
Worse case situation, the ITK User releases an application to a
Application User and that application user loads/generates data that
the ITK User didn't expect. That data is then passed to a method in
ITK that calls another method in ITK that calls another method in ITK
that calls abort (via assert)...and the program crashes.  If I was the
ITK User and the program crashed in a such a manner, I'd certainly
tell the Application User that is wasn't my fault, it was ITK's fault,
and I'd trash the good reputation of ITK.   Also, I'd be left with
either choosing not to use ITK or having to go through the ITK code to
find out what is the meaning behind the abort and how my code brought
it about.    That is, the ITK User will be forced to look at ITK's
.cxx/.txx files...yuck.

Or consider the even worseter :) case, the same above situation but
with the code compiled in Release mode....now the ITK User is really
out of luck...the code is not going to crash or even throw an
exception where the error would have been detected if an exception had
been used instead of an assert...but since the assert becomes a nop in
release mode, the program will happily continue on with the
out-of-bound index (for example) until some memory overwrite or other
down-the-line failure occurs.   Such delayed and secondary
consequences can truly be a bear to resolve...particularly if you're
an ITK User and not an ITK developer.

Consider it another way....aborts are like cout's and cerr's in
library routines given to others.  Cout's, cerr's, and aborts are
great for the original ITK Developers, but really suck for anyone (an
ITK User) who wants to use the code in the future - neither couts,
cerrs or aborts can be handled gracefully by ITK Users...exceptions
can be handled by ITK Users.

Moral of the story -- yup, asserts are great for ITK Developers, but
the minute you check code into the ITK repository it is potentially
distributed to ITK Users...and they need exceptions and not aborts.

> Because it can be quite time consuming (when used in a loop, or to validate
> a tree property for exampe) and it exits quite badly (but that's useful for
> debugging)

Regarding speed...In most ITK applications, I seriously doubt a check
for an exception is going to have a notable impact on performance
relative to other computation costs in ITK.   In the rare, inner-loop
cases, if you feel the exception test is going to be too
expensive...leave it out and then document in the .h that the program
doesn't check but expects (for example) the input to be in a certain
range.   This is what we've done in the past in ITK.   We shouldn't
change our policy now.   A abort is not a solution.

> Exception would also be a way to do the same job, but it requires to
> carefully catch exception in ITK code, to not mask the exception sent by the
> assert-like method - is it really useful?

Exception are more informative than asserts - an abort is
"informative" only to the ITK Developer who placed the abort there.
Again, ITK is meant to be used by many other programmers to develop
applications.   We must give them the opportunity to deal with
unexpected data as appropriate for their application.


Stephen

-- 
Stephen R. Aylward, Ph.D.
Chief Medical Scientist
Kitware, Inc. - North Carolina Office
http://www.kitware.com
(518) 371-3971 x300