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 17:26:43 GMT
Stas Bekman <stas@stason.org> writes:

> Joe Schaefer wrote:
> > 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.
> 
> Frankly, I don't understand why anyone will want to ignore errors and
> therefore why it has to be configurable.

OK- agreed in principle.  However, if a parser fails and the user
traps the error, they might also need to know how more details 
about the failure than can be supplied through $@.

Take this for instance:

  my $req = Apache::Request->new($r);
  my $data = eval { $req->param("foo") };

  if ($@) {
    # user still wants to know if the "foo" param is available,
    # because it may have been available (through param()!)
    # prior to the parser entering an error state.   How do we
    # retrieve the "foo" param now?
    
  }

-- 
Joe Schaefer


Mime
View raw message