[Grok-dev] using zope.testbrowser to test for Unauthorized exceptions and updated zope.publisher with IReRaise exception support
janwijbrand at gmail.com
Tue Sep 22 06:00:22 EDT 2009
Martijn Faassen wrote:
> JW, could you add a note to the upgrade notes about this?
> Uli Fouquet wrote:
>> In general I'd agree, especially about the
>> 'set-handled-exceptions-in-the-ini-file' point. It would really be nice
>> to be able to set these stuff in an .ini file. But three things come to
>> my mind:
>> * what you call "normally" here, is only the behaviour of the publisher
>> for the last years. Changing behaviour only to protect people from
>> setting up their tests differently is not a really strong argument to
>> me, although I can really understand the trouble.
> Well, the tests depended on such a behavior of the publisher too. :)
Added to this point is that the change in publisher behaviour is now
"universal" where it really is only needed in one very particular case:
wrapping zope in the exception catching middleware. Something you do not
need to do in (functional)tests nor when running "production".
>> * I am undecided about having two different behaviours for grok when
>> used in a WSGI-based debugger pipeline or not. Could that confuse
>> developers in any way?
> I share your concern here. I think ideally in the future the browser
> tests should be run against the WSGI app.
That's an interesting idea. But not available soon I suppose.
>> * There are ongoing thoughts about changing the general way of marking
>> the exceptions you want to "keep inside". See
>> I'd support the suggestions made there but this would mean that we
>> had to change our IReRaiseException registration anyway (at least,
>> probably, when it comes to a ZTK-KGS compatibility redesign of grok).
>> So maybe we should wait until this zope.publisher change (which is
>> likely to come) arrived?
> I'm not sure this particular proposal would help much in fixing JW's
> issue, though...
>> Overall +0.5 for the change.
> I'm on the fence on configuring things when the WSGI app is set up too.
> It'll obscure the place of configuration as it won't be grokked or
> coming through ZCML...
Semantics question: "On the fence" means "more or less undecided yet"
right? Or does it mean "Screaming on the fence not to ever ever ever do
I would not like to have the registration obscured in the
grokcore.startup code principly.
However, if the exceptions that will not be reraised can at least be
configured from the debug.ini then people will have a better idea what's
going on - maybe an even better idea then currently, since now the
adapter registration for IReRaise is done in Grok's configure.zcml which
is not immediately visible either (albeit still more visible than
grokcore.startup code of course).
Would people agree if I tried to implement the IReRaise configuration
from debug.ini on a branch of grokcore.startup? Or do people think that
would generally be a bad idea anyway?
More information about the Grok-dev