Dear Jason, thanx for your message.
> Asserts are not present in release code, so they should never > contain code that has side effects. Yes, that is true. Asserts are only checks, thus never put something in an assert with a side effect that is missing when the assert would not be there which is usually the case for the non-debug version on an application. > An assert should never be used for ordinary error conditions that > need to be checked for delt with by the program. I agree, too. Asserts are not for error handling, but for checking if the program still have a consistent state and is doing what was intented to do. If something could go wrong in the normal program behavior, e. g. open a file fail, this must be handled by some useful code which does not simple stop the application (what an assert always do). Though I think: - everything what could go wrong e. g. because of a user interaction, must be handled by the program, even the user may misuse the program totally. - everything which should never go wrong (the theory), but may go wrong for some reason (the reality), should be checked by an assert (the check of a precondition). This even become imho more important if the failure could cause a disastrous result, e. g. a SigSegV, which is usually hard to trace back. > Used properly I would almost say you do not need permission to add > asserts. I normally add them all over the place. Unfortunately > like you I was nervous about using them when it doesn't seem to be > wide spread in Blender, so I refrained. Thanx for this clarification. I just wanted to make sure, what is the intention. Thus I will add also asserts() now when this seems to be helpful. Torsten _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
