On 12/25/2011 04:08 AM, Daniel Shahaf wrote:
> Mark Mielke wrote on Sat, Dec 24, 2011 at 19:01:07 -0500:
>> All code has bugs, of course, but from what I'm reading Subversion
>> is doing something particular in that the developers are treating
>> assert() as a list of TODO items that are not properly handled and
>> really should be handled...
> We do not use asserts as a todo list.
Well you trimmed the part of my post that describes why I think this...
that is, if assert is raised in production, it probably means the code
wasn't properly tested in the first place.
assert() is a dilemma. If you know enough to write the assert, you can
probably write a little more to handle the situation in some way. Not
stop, but at least pass the error back through the stack in some sort of
reliable way.
The case where you don't know enough about how to handle the situation,
you probably didn't know to add an assert().
I don't want to really get into yet another philosophy debate on this -
as the Subversion developers definitely have their own feelings on these
matters - but I do want to point out that other that I don't think this
practice is typical. assert() doesn't make your code better. It just
lets you mark which parts of the software that the authors failed to
provide adequate error handling, and the choice being made is to give a
horrendous looking failure to users instead of putting in the effort to
make it fail in a smarter way.
Then this allows the statement that "I'd rather have it fail than
proceed to do it wrong." The best answer is to do it right. To fail or
do it it wrong are a rock and a hard place.
--
Mark Mielke<mark_at_mielke.cc>
Received on 2011-12-26 01:31:31 CET