> From: Greg Stein [mailto:[EMAIL PROTECTED] > > On Fri, May 10, 2002 at 05:13:44PM -0400, Cliff Woolley wrote: > > On Fri, 10 May 2002, Aaron Bannert wrote: > > > > > > if (my_apr_err) { > > > > ..uh-oh... > > > > } > > > > > > this one bad. > > > > > > > > > > if (my_apr_err != APR_SUCCESS) { > > > > ..uh-oh... > > > > } > > > > > > this one good. :) > > Stylistic nits, but both are *WAY* better than the macro. > > >... > > Do we really need the ERROR_SUCCESS and NO_ERROR thingies? Do they ever > > If a function returns non-zero for *success*, then the function is buggy. > > When apr_status_t was first designed, the one and ONLY requirement for it > was that "success == 0". By DEFINITION, an apr_status_t will and must be > zero if success occurred. > > Thus, the macro is bogus, and the platform specific NO_ERROR and whatnot > is > totally bogus (because the relevant functions should NEVER return that). > > Bill Rowe pointed out that EINCOMPLETE is "success". However, it isn't > really "success" in the same sense. It is returning status information, > which an application can use to direct its flow, but it is not the > unequivocal "success" defined by APR_SUCCESS and the value 0. I'm not sure > that it enters the discussion here at all. > > [ functions that perform work successfully, yet need to return something > to > indicate "hey, I'm not done" or "you need to give me more data" or > whatever should have those alternative "error" values well-documented in > the header file. apps will test against those values to determine what > further action needs to happen. ]
++1 to everything in this message! Ryan
