Hi Paul,
You expose a good use case. The solution below has some drawbacks because
you might want to post-process a request in error, for example to add a
status representation like the StatusFilter do in NRE. Even the proposed
test on doHandle() could be limiting (even if it does solve your issue).
Here is what I propose : let's add boolean return parameters to
beforeHandle() and doHandle() that will determine whether the processing
should continue with doHandle() or afterHandle() respectively. We can make
this backward compatible easily and add it to 1.1 M2.
How does it sounds?
Best regards,
Jerome
2008/1/10, Paul J. Lucas <[EMAIL PROTECTED]>:
>
> At a minimum, handle() should be something like:
>
> public void handle( Request request, Response response ) {
> init( request, response );
> beforeHandle( request, response );
> if ( response.getStatus().isSuccess() ) {
> doHandle( request, response );
> if ( response.getStatus().isSuccess() )
> afterHandle( request, response );
> }
> }
>
> although I'd still prefer the use of exceptions.
>
> - Paul
>
>
> On Jan 9, 2008, at 10:23 PM, Paul J. Lucas wrote:
>
> > And to make matters worse, Filter.handle() is final, so I can't
> > override it to fix it. Sigh....
> >
> > On Jan 9, 2008, at 10:12 PM, Paul J. Lucas wrote:
> >
> >> If I write my own filter and use its beforeHandler(), I would like,
> >> upon some catastrophe, to abort the entire request and return some
> >> client error code.
> >>
> >> Unfortunately, it doesn't appear that the API for Filter allows
> >> aborting a request. True?
> >>
> >> This is another good case for using exceptions.
>
