Garrett Rooney wrote:
> On 2/14/06, Julian Foad <julianfoad@btopenworld.com> wrote:
>
>>>That obviously means we can't use assert to check function arguments,
>>
>>Not true. If one accepts that "assert" is allowed at all, it's perfectly valid
>>to check arguments of private functions because we know all the callers and
>>what they can do. As for public APIs, that's partly what the debate is about,
>>and the answer is far from obvious.
>
> That's not exactly true either. We've had (for as long as I can
> remember) a policy that we don't explicitly check for valid arguments
That's at least the second time someone's said, "We've had a policy". I would
say instead, "We've had a habit." I haven't heard a good argument for this habit.
> to ANY API calls, if a caller passes us bogus data (i.e. a NULL
> pointer to a function defined to not take NULL pointers, etc) we
> crash, with the end result being that these sort of problems are
> usually found quickly and fixed. There's no real difference between
> enforcing such things via an assert and enforcing them via the fact
> that we dereference a NULL pointer a few lines later.
That's not exactly true either. :-) That's true only for invalid pointers
(and possibly a few other things like division by zero), but not true for other
parameter errors such as the one we encountered just now where two objects are
supposed to match but don't.
I don't generally want to see assertions to catch null pointers, because the
hardware does it for us much more efficiently. That doesn't address the
question of when it's good to use "assert" for other checks.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 14 19:52:34 2006