Qtopia-interest Archive, March 2008
Musings on Asserts
Message 1 in thread
Hey,
first of all the usage of assert is great. If you think about the pre- and
post-condition and requirements testing them with asserts is really good and
applaude.
But what does an assert mean? Well, if it is compiled in the application will
terminate. If it is not compiled in and the violation is grave it will crash.
Let me examime both things.
Compiled in and terminate:
How big is the violation? E.g. recently we had a small oversight in WebKit
and hit an assert if we wanted to paint a ListboxAppearance (for the <select
element). This means whenever someone wanted it be drawn, a browser would
exit, taking down his 12 open sites, the three texts he was currently
writing. How grave was the violation? Did it justify this behaviour? It was
not grave at all, it did the right thing. So what we did we made this assert
a runtime check, we are happy, users are happy.
Not compiled in and crash:
Imagine the assert would be hit and the app is crashing in the field on start
up. Every time qpe starts it will segfault and get restarted. The only way
this user gets a usable phone again is to remove all his personal belongings
(factory reset). A user constantly forced to factory default his device will
not be a happy user.
My pledge:
- Use asserts for obvious API abuses
- Make more runtime checks, recover from errors, propagate the error to the
user, provide hints how to resolve it....
kind regards
z.
PS: I'm hitting asserts in the below and think they would be candidates to
less strict error checking:
QPimSqlIO::startSync, CellModemManager::pinStatus
PPS: g_return_if_fail comes into my mind, a good assert replacement with
runtime warning.
--
[ signature omitted ]
