On Mon, 6 Jan 2003, Florin Iucha wrote:
> On Mon, Jan 06, 2003 at 04:19:35PM -0800, rbb@rkbloom.net wrote:
> > Asserts are generally a bad thing IMO. If something should be checked in
> > debug code, it should also be checked in production code.
>
> Asserts are not for argument checking.
>
> Argument checking is for verifying inputs to your module/function/method.
> Asserts are used for internal consistency checking.
>
> Application
> -----------------
> Module interface (public methods)
> -----------------
> Module implementation (private methods)
>
> You would put argument checks in the interface methods and add asserts in the
> implementation methods.
> So if you have a class Array with a method getAt(i) you would verify
> that
> i < arraySize
> but you would assert that
> arraySize <= allocatedArraySize.
I understand that, but my statement still holds. If you are going to
check something, then it should be checked in both debug and release
builds. Since asserts are not used in production code, they are not
generally useful. If something needs to be checked, then it needs to be
checked, regardless of build type.
> > As for pointers
> > being passed without checking for NULL, those checks are usually a waste
> > of cycles. If the value is incorrect, then you are most likely to catch
> > those problems in your debugging. You are more likely to catch those
> > problems if your program segfaults than if you rely on a log message that
> > you may miss.
>
> And what if it does not segfault but randomly scribbles some buffer
> before commiting to database? A wild pointer access will segfault only
> if it points to memory the OS knows you should not have. If it points
> to allocated memory, you get random coruption.
Then that behavior should also be noticed. Either the data will be
corrupted or a log file will end up having junk in it. Those problems
should be caught by either a compiler warning (all programs should compile
clean), a seg fault, or a failed test (usually found through a log
message). Argument checking moves the failure to the last option. But,
that is bad, you want to catch things as quickly as possible, which means
that a seg fault is actually better than an error message. The logic
behind this is simple enough: A log message or return code is easy to
ignore, a seg fault is impossible to ignore. Once your code seg faults,
you basically have no choice but to fix the code.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 7 01:59:21 2003