httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: status and error handling in apreq2
Date Tue, 29 Jun 2004 12:49:44 GMT
Stas Bekman <stas@stason.org> writes:

> Joe Schaefer wrote:
> > It's time to implement Apache::Request::status,
> > and looking over the current code, there are
> > a few shortcomings that we should also address:
> >   1) the status attribute in apreq_value_t is not
> >      useful, and it should be dropped,
> >   2) we need a way of recording and reporting 
> >      whether the query_string parse was successful,
> >      so adding an args_status field to apreq_request_t
> >      seems logical,
> >   3) ditto for parsing the "Cookie" headers-
> >      add a status field to cookie_jar_t.
> > Then we can expose those fields in Perl,
> > so users have a way to detect such problems.
> > Also adding a $req->body_status that reports
> > the active parser's current status would make
> > a nice implementation of $req->status possible:
> >   sub status {
> >     wantarray ? ($req->args_status, $req->body_status)
> >               : $req->args_status || $req->body_status;
> >   }
> > Thoughts?
> 
> FWIW, I think it's the best for apreq2 to throw an exception when an
> error happens, making the errors trappable, when users want to handle
> it (which most users won't do anyway), like mp2 now does.

That's a good idea, we might even be able to make that
configurable with a "RAISE_ERROR => 1" argument to new().
Either way, (1) - (3) are necessary to make this happen,
because users have very little control over *when* things
happen in apreq2.


-- 
Joe Schaefer


Mime
View raw message