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

David Cole david.cole at kitware.com
Mon Aug 11 07:43:34 EDT 2008


assert should be used to indicate that something "impossible" has
happened...

But, as we all know, sometimes programmers assume that something that's
really possible is impossible.

asserts are very good in debug builds at being a first indicator that
something has gone wrong. They are also very good at guaranteeing a very
dissatisfying end user experience in a release build, when the program just
stops, hangs, freezes or vanishes quite unexpectedly. So they need to be
used carefully.

asserts are a valid technique to have (even in production code) when the
condition being checked is truly impossible, given *any* data as input.
Otherwise, they are simply not appropriate.

For further reading, there's a good wikipedia article on the topic, too:
http://en.wikipedia.org/wiki/Assertion_(computing)


On Mon, Aug 11, 2008 at 4:42 AM, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr
> wrote:

>
> Le 11 août 08 à 00:54, Stephen Aylward a écrit :
>
>  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().
>>
>
> Hi,
>
> I think assert() is a high added value in the code, and that we should keep
> them as most as possible. 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. For example, the assert in
> vector::operator[] was a good way to find a bug in
> SignedMaurerDistanceMapImageFilter a few weeks ago.
>
> 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), this is typically the kind of thing we want to do only in debug
> mode. When building an application in Release mode for production, assert()
> expends to nothing, which is quite nice.
>
> 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?
>
> Also, I agree that some check must be left in production code, but in that
> case, they must throw a catchable exception with a clear error message - not
> only a line of code with var names as in asserts.
>
> Gaëtan
>
>
>
>
>>
>> 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
>>
>
> --
> Gaëtan Lehmann
> Biologie du Développement et de la Reproduction
> INRA de Jouy-en-Josas (France)
> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
> http://voxel.jouy.inra.fr  http://www.mandriva.org
> http://www.itk.org  http://www.clavier-dvorak.org
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20080811/d7966afd/attachment.htm>


More information about the Insight-developers mailing list