apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: Memory code...
Date Fri, 11 May 2001 08:48:30 GMT
David Reid wrote:
> 
> Hmm, replies inline.
> 
> > > Not our call is it?  We're a library, so if the user wants to abort on a
> > > call of APR_EINVAL then that's their business.  We're simply telling
> them
> > > they passed in an invalid handle.  Chances are they'll ignore it.
> > >
> > > Roy's recent email about asserts in libraries makes interesting reading.
> > > I'm in favour of removing a lot of the asserts once we've got things
> more
> > > stable and have "proved" the code more thoroughly.
> >
> > I've followed this one a bit too. I think you should make a distiction
> > between users of a library(lets call them users) and developers of a
> library
> > (lets call them developers).
> > For developers asserts are a great tool for finding bugs in the library.
> > They really should not be removed.
> > Furthermore, asserts are good to enforce certain user coding. Passing
> > NULL pointers is generally a bad thing and checking for them is just
> > overhead that can be avoided.
> 
> We only check for NULL pointers where they would cause segfaults and are
> passed in due to an error.  I'd rather pass back an error to the caller so
> that the code that has the error can be fixed.  In fact it may be that the
> caller doesn't care and will happily carry on, not an option with an assert.

But the caller can simply not call if it doesn't care (since it would
know in advance that it is going to get an error).

I've never bought the argument that you should return an error when
things are clearly screwed - no program is going to unscrew them, and
carrying on running a program that has damaged its data (or has logic
errors) is just plain foolish. There may be some mileage in the idea
that you should die in a way that permits cleanup, but even that is
pretty risky.

What I do agree is that using asserts where you _should_ return an error
is bad (and I know I'm sometimes lazy about this :-).

> > I generally agree that some asserts could be removed or replaced, but
> > for the rest I'm in the group of people that like code to bomb out
> > and not silently fail or continue.
> 
> I agree about the asserts being useful for devlopers, which is why they're
> still there, but once we have the code basically working I'm in favour of
> reducing the quantity that we have in the code.  The use of asserts to
> find/debug specific problems is good.

Don't reduce them, just selectively switch them off, IMO.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Mime
View raw message