On Mon, May 12, 2014 at 10:08:08PM -0300, Tomaz Canabrava wrote: > > We can achieve that by throwing an error. but since we didn't hit any > Q_ASSERT till now on the code I think we are pretty safe. :) > or if you prefer I can readd the check for nulls.
The Q_ASSERT are only triggered in Debug builds, but all the end user builds are Release builds, so we wouldn't see them if our users are hitting them. That's why there were both Q_ASSERTs and if (d == null) checks. At least I hope that's why we had both of those. :-) I think we're fine as is (that's why I pushed the change). I don't see how we could end up with invalid ids. But fact is that this is bad programming practice. And I'd like to do an audit of the code and look at all the places where we COULD get a null pointer back and then dereference it and create a way to handle all of them in a sane manner without crashing. /D _______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
