is it not necessary to be checking whether the values of data objects will be in a consistent state even during release code? or in that case will you change these assertions in the model to exceptions in the controller or something like that?
I see your point. You should be testing that those assertions are true everytime the code is run... even in release mode. Maybe it would be a good idea to leave some assertions - some extremely important ones - enabled and disable others. And if and when an assertion does fail, to catch the AssertionFailed exception gracefully and display a message to the user.
But my feeling is still that assertions are a debug tool. They are there to help the programmer from his own errors. Any input errors made by the user should be handled by exceptions. Same with invalid arguments passed into methods by other programmers... exceptions are the way to go.
You will test your app in the debug build with all assertions turned on. You run a whole bunch of tests and no assertions fail. You are reasonably satisfied with it... to some degree. That allows you to turn off the assertions.
In the code you provided, the static booleen variable is there to turn off assertions. Why would that be there, if it wasn't optional? As in, with the intention of being turned off at some point. Some books say to "assert everything". You can take that to mean whatever you want... but it is essentially saying use it liberally. If you do that, it will slow down your app. So to speed up performance, you would need all them assertions disabled when you release it.
No comments:
Post a Comment