[Grok-dev] Final touches for a 1.0 "proper"
faassen at startifact.com
Thu Oct 1 10:39:17 EDT 2009
Jan-Wijbrand Kolman wrote:
> Martijn Faassen wrote:
>>> * It is not really a show stopper, it would be nice if someone (Martijn,
>>> Uli?) could have a look at what I skethced out here:
>>> See also the earlier "using zope.testbrowser to test for Unauthorized
>>> exceptions and updated zope.publisher with IReRaise exception support"
>> I took a look at it. How is exempt-exceptions configured?
> Like I In the debug.ini file for your grokproject, something like:
> use = egg:Debugging#debug
> filter-with = translogger
> exempt-exceptions = zope.security.interfaces.IUnauthorized,
> Ofcourse, grokproject will generate one for you with the IUnauthorized
> exempt already in there.
I took a bit more context to figure out what this was about again. I
think a recap of the original problem and a few hints about the shape of
the solution would have helped put the whole problem into my mind again.
>> I think this needs some documentation on when and how one would use it.
> Sure, but I wanted some feedback on the approach first.
> Do I understand that people generally agree on this approach? Surely we
> need to document the behaviour, for example in the upgrade notes.
So here is my thinking process to try to figure out what this was about
The original problem was that Unauthorized was not handled in zope
proper if the zope publisher was configured not to handle any exceptions
itself. This is bad in debug mode with WSGI. We added a modification so
we can configure the zope publisher not to reraise some exceptions like
Unauthorized if things are configured that way.
Now when you run functional tests this gives you a problem as you expect
Unauthorized to be there if you set handle_errors to false, but now it
isn't. Is that correct? I think that's a bug, as handle_errors to false
means we never want to handle any errors in the publisher, including
unauthorized. The tests should be run in a way so that when
handle_errors is False, the reraising behavior is turned off entirely.
Now somehow a feature to add to debug.ini those errors we don't want to
reraise helps with this issue. Why?
The missing idea in my mind is that we wouldn't configure this reraise
exception behavior in ZCML at all anymore. Instead we'd only put it in
That sounds reasonable.
+1 for going ahead with that approach. Feel free to reuse some of the
above text for the documentation/upgrade notes.
More information about the Grok-dev