Hi Paul, 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).
I was thinking that the Filter subclass could override the doHandle() method and change the default behavior which would always return 'true'. 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. Instead, we could become more precise and return an int with associated constants (CONTINUE | SKIP | STOP) or (DO | AFTER | RETURN). What that solve your use case nicely? Best regards, Jerome
