[Grok-dev] Final touches for a 1.0 "proper"

[Martijn Faassen]

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:
>>>
>>> http://svn.zope.org/grokcore.startup/branches/jw-configurable-ireraise-adaptation/?rev=104430&view=rev
>>>
>>> See also the earlier "using zope.testbrowser to test for Unauthorized 
>>> exceptions and updated zope.publisher with IReRaise exception support" 
>>> thread.
>> I took a look at it. How is exempt-exceptions configured?
> 
> Like I In the debug.ini file for your grokproject, something like:
> 
> [app:zope]
> use = egg:Debugging#debug
> filter-with = translogger
> exempt-exceptions = zope.security.interfaces.IUnauthorized,
>                      some.other.interface.ISomething
> 
> 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 
again:

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 
debug.ini.

That sounds reasonable.

+1 for going ahead with that approach. Feel free to reuse some of the 
above text for the documentation/upgrade notes.

Regards,

Martijn