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

Reply via email to