Well, if you want to post-process a request in error, you need to
distinguish that case from the case where you don't want to post-
process in error.
Another problem is that the current doHandle() calls next.handle()
and that doesn't return a boolean to indicate whether to do post-
processing in error. So, even if you make doHandle() return a
boolean, it's not clear what you return since it has no way to know
whether it should continue (unless it checks the Status code).
There's also the case where, even if you return false from
beforeHandle(), you might still want to call afterHandle(), no?
So if you really wanted to cover all cases, you'd have to do
something like:
boolean beforeSucceeded = beforeHandle( request, response );
if ( beforeSucceeded )
doHandle( request, response );
afterHandle( beforeSucceeded, request, response );
If you don't want to post-process, then the implementation of
afterHandle() can check the Status code itself and do nothing on error.
The added parameter of beforeSucceeded to afterHandle() would be
needed to distinguish the case where beforeHandle() failed (and thus
doHandle() was never called) vs. doHandle() failing.
- Paul
On Jan 10, 2008, at 12:08 AM, Jerome Louvel wrote:
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?
