beginErrorHandlingTransaction called in two contexts with fragile discriminator

Bug #293614 reported by Gary Poster
2
Affects Status Importance Assigned to Milestone
Zope 3
Won't Fix
Undecided
Unassigned
zope.app.publication
Confirmed
Wishlist
Unassigned

Bug Description

We have code in our error reporting utility that records what happened in a request. Then, before getting the exception view, we need to reset our records, so if something goes wrong there, the delineation is clear when we record *that* in our error reporting utility as well.

In zope.app.publication.zopepublication.ZopePublication, handleException calls _logErrorWithErrorReportingUtility, which calls beginErrorHandlingTransaction with (request, object, 'error reporting utility') before getting the error reporting utility. handleException then later calls beginErrorHandlingTransaction again with (request, object, 'application error-handling'). If there is an error in the exception view, handleException calls _logErrorWithReportingUtiliity again.

We need to leave our "what happened" data structure intact for the first call to beginErrorHandlingTransaction, or else the error reporting utility won't be able to use the records. In the second call, we need to clear out the records, so the error view has a fresh slate.

Right now, our only choices are to override handleException, which is unappealing because then we would have to copy all of the method's code to insert our logic in the right place; or to override beginErrorHandlingTransaction and distinguish on the note argument, which is unappealing because it is fragile and not part of any interface (for that matter, none of the methods listed here are, except handleException). We are distinguishing on the note argument and relying on tests to combat fragility, for now.

We would prefer to have a documented way to distinguish between the contexts in which beginErrorHandlingTransaction is called. For instance, different methods; or dividing up the steps of handleException in such a way that we can hook into the right point without overriding the entire method; or constants rather than strings; or at least an interface describing the strings so it is clear that it is reasonable to rely on them.

Tags: tech-debt
Curtis Hovey (sinzui)
tags: added: tech-debt
Changed in zope3:
status: New → Won't Fix
Changed in zope.app.publication:
status: New → Confirmed
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.