apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: cvs commit: apr/misc/unix errorcodes.c
Date Sat, 19 May 2001 22:04:08 GMT
On Sat, 19 May 2001, David Reid wrote:

> > For example, I don't see why these newest ones that've been added can't be
> > handled within the definition of existing codes.  Why can't APR_ENOTIMPL
> > and APR_EINVAL do the job here?
> >
> > Then there's the problem of an error code sounding bigger in scope than it
> > is.  APR_ENOCLEANUP is a perfect example.  If we're going to have a code
> > named like that, then why should it be limited to being used only by the
> > memory system?  Why wouldn't that be used in more general cases?  (I can't
> > think of a good example at the moment, but I hope you see what I'm getting
> > at anyway.)

> I agree with some of your comments.  I'll change to NOTIMPL where
> appropriate but the NOCLEANUP could be used elsewhere...  The MEMSYS is
> going to stay in as we need some way of signalling the problem.  If we're
> passing in 2 values which is invalid?

I thought about that.  But does it really matter?  It's the caller's
responsibility to pass in good arguments.  If they don't and we fail
because of it, all we have to tell them is that we failed.  What good
would it do them to know which argument was invalid?  It's not like
they've going to fixup that argument and call us again, right?  Also,
aren't there other places in the code that generally just use APR_EINVAL
even when one of several arguments could be the invalid one?

Anyway, if you still think that MEMSYS should stay, then that's fine.  I
won't argue it.  I just wanted to voice my general objection to the
proliferation.  =-)


   Cliff Woolley
   Charlottesville, VA

View raw message