Well I can (as normal) see both sides of the argument :) I've done the change for APR_ENOTIMPL as I agree that's probably better than having more error codes, but I'd rather we try to give the user as much information as possible. If people feel strongly enough we can move to APR_EINVAL, but I like the fact that EMEMSYS tells the user where the error is exactly. While at present we only use a != NULL as the test, I can easily imagine we find a minimum criteria and check for them. for instance, imagine we're loading a shared module at runtime that says it's a memory system. If it fails out checks (eg doesn't have a free and malloc function) we'll return EMEMSYS.
As for the ENOCLEANUP, well that could be removed, but if we're passing in 5 arguments it's nice to be able to return an error code that gives the user more of an idea as to which one had the problem, which is what we do with the ENOCLEANUP arg. Returning EINVAL doesn't really give the user much information does it? Anyway, I'm on holiday now for a week so when I'll get back I'll think about this stuff again :) Until then, have fun y'all!! david > 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 > > -------------------------------------------------------------- > Cliff Woolley > [EMAIL PROTECTED] > Charlottesville, VA
