Should one leave asserts in production iOS apps?

Question

Common practice might be to put asserts in code to check input parameters, data integrity, and such, during app development.

I test my apps, BUT, given that I\'m not K

Answer 1

There always tends to be something better to do in production code then fail an assert, but sometimes the trade off is less cut and dried.

A good time to assert: when continuing on will destroy user data ("there is a known good save file already, and I've detected damaged data structures, if I write over the good file with what I have I'll destroy it"). Obviously the "best" option is to not damage the data in the first place. Second best is to detect damaged data during the save and save to a new file (it might be loadable, or maybe what is in it is valuable enough to salvage via heroic means).

Another good time to assert: when you know continuing on will crash (passing NULL to many plain C functions, about to divide by zero...). The assert will carry more useful information. Of corse even better is not getting into that state. Second best is aborting the operation, not the program ("I can't print" is better then "I threw away your unsaved data, and by the way you can't print").

You can pretty much always break things down like that. However error recovery is pretty complex, and handing some errors will double or worse the size of your code for something that may never happen...and then you have to figure out how to test it, and...

...so it is a trade off. What else in your program will be better if you skimp on error recovery? Will it be enough better to make up for the extra crashes?