On 3/7/10 7:36 PM, Andrey Popp wrote: > Yes, I know I can make it work by returning webob.exc.HTTPException > objects as response. But the point was to decode JSON request at view > initialization phase and raise webob.exc.HTTPBadRequest if needed, so > in subclasses at request processing phase (__call__ method) I always > will have well-formed request objects.
That makes sense. If I weren't the author of the framework, and someone suggested that converting WebOb exceptions to responses shouldn't be a feature of the framework, I'd think they were being pretty silly. But features are *the enemy* of frameworks, so as the author I feel compelled to provide a counterargument even if I don't really believe strongly in it. ;-) Apologies in advance. In that spirit I'll note these things: - you could use a decorator for the same purpose instead of relying on the framework to do it for you. It would be a pretty stupid decorator, but it would work. - you could insert the webob.exc.HTTPExceptionMiddleware middleware into your WSGI pipeline; this indeed converts webob exceptions to responses. This is another way of "extending the framework". > By looking at the Router code it seems that handling > repoze.bfg.exceptions.NotFound/Forbidden is some kind of bonus feature > for views, because it is more intended for serving repoze.bfg.security > and context finding/view lookup mechanisms, isn't it? Originally they were only intended to be raised within views, but we changed things around so they can be raised within root factories and so on. - C _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
