On 3/8/10 7:41 AM, Andrey Popp wrote:
>> 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.
I understand the purpose and the argument already. I'm just saying that there
are existing options that don't require it.
>> 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,
INewResponse is almost useless, I should have never added it, but I can't
remove it now (feature-fear isn't always irrational!). Middleware should
almost always be used instead. See the apologetic sidebar in
The idea that we'd use the existence of this misfeature as a rationale to add
more features is not good.
> even repoze.bfg.exceptions.NotFound and webob.exc.HTTPNotFound will
> not be semantically equal. That is not a good thing.
The fact that these two exceptions are named similarly doesn't necessarily mean
they should be handled the same. If someone is currently using
webob.exc.HTTPExceptionMiddleware, they are depending on the exception bubbling
In particular, if we do catch webob.exc.HTTPNotFound in the same exception
handler currently serviced by r.b.exceptions.NotFound, it will mean:
- a behavior change that may break folks who already rely on middleware
to convert webob exceptions to responses.
- an invitation to convert other webob exceptions into responses within the
router. For instance, if we went purely by name similarlty, HTTPForbidden
would then logically need to be caught by the current Forbidden exception
handler. Then we'd need to start to argue about whether HTTPUnauthorized
should map to the Forbidden exception handler, and so on.
- we'd open up the door to asking for other special purpose exception views.
We might be asked to add other special case exception handlers and exception
views based on WebOb's various exceptions; I could see someone asking for a
"500" view when any 500-series webob exception was caught.
It just becomes a bit of a rabbit hole. The rabbit hole is avoided entirely if
the we document that people should just put the
webob.exc.HTTPExceptionMiddleware middleware into their WSGI pipeline if they
want WebOb exceptions to be converted to responses.
OTOH, it'd be reasonable to provide a generic "exception view" facility like
Zope's where users can map any exception type to a particular view; this is
definitely less adhoc and requires less documentation. I'd be +1 on such a
feature, I think. At least without thinking about it really hard at the
Repoze-dev mailing list