>> I was thinking of this too — it is good to return control back to >> application during handling of this kind of errors (4xx). Also it will >> convert notfound/forbidden views from special cases of Router >> processing cycle to special cases of "exception view". >> > > Right, I think it makes sense... do you think you might want to take a stab > at implementing that?
Ok, what about reusing the current view registering/lookup machinery? I mean can we treat exception views as views for context defined by raised exception? So raising exception is just context switching inside request processing. Pros: * We can define different exception views for different request predicates. * Unification with view machinery. Cons: * We cannot access previously located context (if there was one), cause it replaced with current exception context. * We should register exception views for exception interfaces, not classes. This is because adapter lookup uses IRO, not standard MRO. -- Andrey Popp phone: +7 911 740 24 91 e-mail: 8may...@gmail.com _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
