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 Repozeemail@example.com http://lists.repoze.org/listinfo/repoze-dev