httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: status and error handling in apreq2
Date Tue, 29 Jun 2004 17:08:51 GMT
Joe Schaefer wrote:
> Stas Bekman <> 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;
>>>  }
>>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.

Frankly, I don't understand why anyone will want to ignore errors and 
therefore why it has to be configurable. Those who know what they are doing 
can use eval {} to trap errors.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message