You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Manoj Kasichainula <ma...@io.com> on 1999/10/22 23:27:47 UTC
Should buff return error codes on partial success?
I'm in the middle of taking errno out of buff. Most calls that get
changed will soon return an APR-style error code and pass bytes sent or
received back through an argument.
It'll then be possible for buff to return an error code and indicate
that it wrote some bytes at the same time. But, the Unix APIs (and iol
right now) don't do this. Should I make buff return an error code even
if it wrote some bytes correctly, or should it return APR_SUCCESS and
wait until the next call to return the error code?
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
Re: Should buff return error codes on partial success?
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Manoj Kasichainula wrote:
>
> But, I think the bonerror interface is more useful in these situations
> anyway.
Except that I always think of osteopathic malpractice whenever
I see the name. :-)
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://ASFD.MeepZor.Com/>
Re: Should buff return error codes on partial success?
Posted by Manoj Kasichainula <ma...@io.com>.
On Sat, Oct 30, 1999 at 11:16:59AM -0700, Dean Gaudet wrote:
> i was thinking something more along the lines of ferror() on FILE. but
> it's not immediately important.
Well, I've been trying to decide what to do about the buff "utility"
functions that look like stdio functions. I'm leaning more towards
adding a berror() to return an error code for all of these. The first
reason is that the errno isn't checked for most of these, so it just
makes the interface look uglier. The second reason is that I'm lazy.
But, I think the bonerror interface is more useful in these situations
anyway.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
Re: Should buff return error codes on partial success?
Posted by Manoj Kasichainula <ma...@io.com>.
On Fri, Oct 29, 1999 at 10:57:25PM -0500, Me at IO wrote:
> That and bgets.
Ignore that line. blah.
Re: Should buff return error codes on partial success?
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 29 Oct 1999, Manoj Kasichainula wrote:
> > bgetc has to be coupled with an error() function to test what error
> > occured after bgetc indicates error.
>
> Like errno? I guess we could create one of those. There is the
> ap_bonerror mechanism. It's something I've been pondering making more
> use of; it almost gives us the semantics of exception handling.
i was thinking something more along the lines of ferror() on FILE. but
it's not immediately important.
Dean
Re: Should buff return error codes on partial success?
Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, Oct 28, 1999 at 11:35:59AM -0700, Dean Gaudet wrote:
> i don't think it matters much, unless you're proposing to change the bgetc
> macro... in which case i'd say you're on crack ;)
Hmmm. Well, I wasn't proposing it, per se, just floating a trial
balloon. :) Yeah, changing the bgetc macro eliminates its convenience.
That and bgets.
> bgetc has to be coupled with an error() function to test what error
> occured after bgetc indicates error.
Like errno? I guess we could create one of those. There is the
ap_bonerror mechanism. It's something I've been pondering making more
use of; it almost gives us the semantics of exception handling.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"The universe is in fact made up of Fabio." - scientist on _Eek the Cat_
Re: Should buff return error codes on partial success?
Posted by Dean Gaudet <dg...@arctic.org>.
i don't think it matters much, unless you're proposing to change the bgetc
macro... in which case i'd say you're on crack ;) bgetc has to be coupled
with an error() function to test what error occured after bgetc indicates
error.
Dean
On Fri, 22 Oct 1999, Manoj Kasichainula wrote:
> And a related question: the errnos of some buff calls are completely
> ignored, at the expense of streamlined code. Now, in these cases (e.g.
> most uses of ap_bgets), it's probably okay, since we want to treat EOF
> and errors the same.
>
> Should I leave ap_bgets and functions like this with their existing
> APIs (-1 on error, 0 on eof, > 0 = length of string), sans errno, or
> should I switch to the APR New World Order of returning ap_status_t's?
> Doing the latter would give us a great opportunity to add the error
> checking code, but if it's not worth the added code cruftiness, I
> won't do it.
>
> --
> Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
>
Re: Should buff return error codes on partial success?
Posted by Manoj Kasichainula <ma...@io.com>.
And a related question: the errnos of some buff calls are completely
ignored, at the expense of streamlined code. Now, in these cases (e.g.
most uses of ap_bgets), it's probably okay, since we want to treat EOF
and errors the same.
Should I leave ap_bgets and functions like this with their existing
APIs (-1 on error, 0 on eof, > 0 = length of string), sans errno, or
should I switch to the APR New World Order of returning ap_status_t's?
Doing the latter would give us a great opportunity to add the error
checking code, but if it's not worth the added code cruftiness, I
won't do it.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
Re: Should buff return error codes on partial success?
Posted by Manoj Kasichainula <ma...@io.com>.
On Sat, Oct 23, 1999 at 07:56:30AM -0400, Ryan Bloom wrote:
>
> Personally, I would have BUFF return a status code. There is a whole
> section of APR code for status values. This way, it doesn't imply an
> error, just information we should know.
Then, we'd have to create a status code for every single IO error
code. Or do some bitmapping like Ken was talking about to indicate
severity (which would break the matchup with Unix's errno).
The number of bytes read already sort of performs that function, so I
don't think that non-error status codes are strictly necessary. Though
I have yet to completely think through indicating EOF (done right now
by returning APR_SUCCESS and a 0 bytes_read).
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
Re: Should buff return error codes on partial success?
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 22 Oct 1999, Manoj Kasichainula wrote:
> It'll then be possible for buff to return an error code and indicate
> that it wrote some bytes at the same time. But, the Unix APIs (and iol
> right now) don't do this. Should I make buff return an error code even
> if it wrote some bytes correctly, or should it return APR_SUCCESS and
> wait until the next call to return the error code?
i've worked with APIs both ways, and i prefer the unix API. errors or
bytes, but not both. yup, this means delaying some errors until the next
call unfortunately.
Dean
Re: Should buff return error codes on partial success?
Posted by Ryan Bloom <rb...@ntrnet.net>.
Personally, I would have BUFF return a status code. There is a whole
section of APR code for status values. This way, it doesn't imply an
error, just information we should know.
Ryan
On Fri, 22 Oct 1999, Manoj Kasichainula wrote:
> I'm in the middle of taking errno out of buff. Most calls that get
> changed will soon return an APR-style error code and pass bytes sent or
> received back through an argument.
>
> It'll then be possible for buff to return an error code and indicate
> that it wrote some bytes at the same time. But, the Unix APIs (and iol
> right now) don't do this. Should I make buff return an error code even
> if it wrote some bytes correctly, or should it return APR_SUCCESS and
> wait until the next call to return the error code?
>
> --
> Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
>
_______________________________________________________________________________
Ryan Bloom rbb@ntrnet.net
6209 H Shanda Dr.
Raleigh, NC 27609 Ryan Bloom -- thinker, adventurer, artist,
writer, but mostly, friend.
-------------------------------------------------------------------------------