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 
http://docs.repoze.org/bfg/1.2/api/events.html#repoze.bfg.events.NewResponse .
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 
up.

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

- C
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Reply via email to