Kevin Dangoor wrote:
The generalized error_hander mechanism is fine and flexible on the whole. But, I'd still contend that validation errors are of a different breed than actual programming exceptions and deserve mildly special treatment as a result.
OK, what should than happen in case of a error-unaware method with validators? If my understanding is correct, validators assure arguments passed to the method will conform to a certain protocol. Right now (continuing the legacy of _call_with_errors) we deliberately break this promise.
I'd only support moving identity's redirect logic to an error handler if you didn't have to explicitly put references to it all over the place. (@identity.require is nice and easy, and the control flow for the identity piece does not involve the controller, so it's still clean...)
The idea was to create a specialisation for IdentityException less specific than per-method rules so one can override it at any time. But this can (and should) wait. First I want to fully define error handling protocol.
What do you mean by "the URL should be rewritten behind the scenes"? There are actually certain advantages to doing a real browser redirect (users don't keep posting the same form over and over again, for example).
Yes, but why should this consideration influence how I program my controllers? We could for example check in expose() whether URL corresponds to the method being called. If not, a redirect could be preformed without messing about with hard-coded URL and the like.
Simon
