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

[Gaëtan Lehmann]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20080811/6c8c8b92/attachment.pgp>