> 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. 
> ;-)

I like that repoze.bfg reuses webob for WSGI layer, but why not to
reuse exceptions from that package? It is not about features, it is
more about extending view API to allow raise exceptions from webob.exc
(not all probably, but which are inherited from
webob.exc.HTTPClientError). This is like view-lookup can raise
NotFound and repoze.bfg.security — Forbidden.

> 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.

I don't think it'll be stupid because it needs to catch HTTPException
at initialzation, store it, when augment __call__ method and if the
later was raised, it should reraise it during __call__ call.

> - 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".

It seems to be more better way than decorating each view, but it does
not work, because there will be no INewResponse event fired and so on,
even repoze.bfg.exceptions.NotFound and webob.exc.HTTPNotFound will
not be semantically equal. That is not a good thing.

Repoze-dev mailing list

Reply via email to