[vtk-developers] Use of assert

[Mathieu Malaterre]

> Perhaps there should be a "VTK_ASSERT" wrapper that gets used within VTK 
> proper...? That way we can control whether an abort happens or not, at 
> least for the ones that are in VTK source.
> 
> Although, grepping on assert underneath VTK yields quite a large number 
> of "assert" hits within the various utility libs : vtktiff and now the 
> recently added vtknetcdf. So users of those may still be subject to the 
> occasional abort...
> 
> It would be my expectation that an assert is usually a severe 
> programming mistake, something "impossible," followed shortly by a crash 
> of some sort.  A crash is preferable to an abort call nowadays with the 
> "crash reporting" technologies on Windows and Mac.
> 
> For any end-user application (like ParaView) there ought to be no chance 
> of an unexpected abort call - assert code should certainly be a no-op in 
> a "Release" build...

This is done properly by cmake since 2.0 I believe (NDEBUG is properly passed).

> An excellent treatment of this subject appears in the book Writing Solid 
> Code, by Steve Maguire. I definitely recommend reading the section on 
> "assert philosophy" in there.


I don't have the book right now. If you have read it I guess you should be able answer my questions:
Even if you put an assert deep inside a function that is not  called after user input, how can I *guarantee* that broken/illegal user input won't raise the assert ?
The only guarantee I can think of is that the developer has written the assert just after an if statement which duplicate the condition...

Since duplication of code make the maintenance more complicated, I believe we should go for the option you proposed: the crash system. The VTK_ASSERT macro should then call any OS specific system (better than abort).
And we could even controll completely this macro, in my case if I want to debug my code I could always redefine it to my beloved 'assert'.

The only trick in this macro is that we should somehow be able to control it if the 'impossible' happen. For instance in the XML-IO classes there is a mechanism where developer has to specify an error occur by turning a flag ON (member variable of the class).

Therefore the MACRO should take into account:
- the condition,
- the error message,
- the post treatment to do  (portion of code to execute) in a 'Production' product (even compiled in Debug mode).

Comments very welcome
Mathieu