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

[Stephen Aylward]

We've recently had this discussion for one of our projects.

Short answer:  asserts are generally considered bad for production
code (it is like putting an abort() in production code); and
exceptions should be used instead.

Julien Finet found that Bjarne Stroustrup in his book "The C++
Programming Language" has the following to say

""""
Before aborting, a s s e r t () outputs the name of its source file
and the number of the line on which it appears. This makes a s s e r t
() a useful debugging aid. N D E B U G is usually set by compiler
options on a per compilation unit basis. This implies that a s s e r t
() shouldn't be used in inline functions and template functions that
are included in several translation units unless great care is taken
that N D E B U G is set consistently (§9.2.3). Like all macro magic,
this use of N D E B U G is too low level, messy, and error prone.

Also, it is typically a good idea to leave at least some checks active
in even the best checked program, and N D E B U G isn't well suited
for that. Furthermore, calling a b o r t () is rarely acceptable in
production code.
""""

He goes on to suggest replacing assert() with a templated function
Assert<>() that can be more finely controlled and that internally uses
exceptions and not abort().

Stephen

On Sun, Aug 10, 2008 at 2:08 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Gaetan,
>
> You may have noticed some errors in your Review directory code today.
> I had attempted to remove some warnings from the Borland build about
> unused parameters. Unfortunately, I was a bit careless, not noticing
> that there were asserts()'s that used these parameters. Since all of
> my builds are non-debug builds, I didn't notice the errors. As you
> probably saw, I have checked in fixes.
>
> This does bring up a question about the use of assert()'s in ITK code.
> I'm not a fan of using assert()'s since, I believe, after reporting
> the error, they abort the program. Indeed they are only active for
> debug builds, so there may be some justification.
>
> Question to itk developers: Should we allow (encourage) assert()'s in
> itk? There are 205 assert()'s in itk Code/. Of these, 194 are in
> Review. That means 11 are in released itk code.
>
> Bill
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>



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