Re: [Zope] standard_error_message woes!
Chris Withers writes:
John Chandler wrote:
As already mentioned, not all errors (unfortunately) get handled by standard_error_message - authorisation being the main culprit. In addition, if an error occurs in a standard_error_message it'll also cause the plain, default error page to be displayed.
Hurm... I would have thought/it would be nice if an error occurs in standard_error_message then, the next standard_error_message up the acquisition path would get used, resorting to the hard coded one only if there isn't anything else... I do not agree with you here.
You should be able to make "standard_error_message"s that do not generate secondary errors. If you fail, a crude minimal error handling should be okay as a last resort. Dieter
Dieter Maurer wrote:
You should be able to make "standard_error_message"s that do not generate secondary errors. If you fail, a crude minimal error handling should be okay as a last resort.
Hmmm... maybe there should be an option on this then? ;-) cheers, Chris
Chris Withers writes:
Dieter Maurer wrote:
You should be able to make "standard_error_message"s that do not generate secondary errors. If you fail, a crude minimal error handling should be okay as a last resort.
Hmmm... maybe there should be an option on this then? ;-) I think, someone like GvR would call it "feature bloat" ;-)
Dieter
You should be able to make "standard_error_message"s that do not generate secondary errors. If you fail, a crude minimal error handling should be okay as a last resort. The Lisp system on Symbolics had both. It had a too-many-error-frame detector for the error reporter that used a crude system when triggered. It would be nice that the crude error messages be settable in a way that is hardended, perhaps env vars? FYI, Albert Boulanger aboulanger@vpatch.com http://www.vpatch.com
albert boulanger wrote:
You should be able to make "standard_error_message"s that do not generate secondary errors. If you fail, a crude minimal error handling should be okay as a last resort.
The Lisp system on Symbolics had both. It had a too-many-error-frame detector for the error reporter that used a crude system when triggered. It would be nice that the crude error messages be settable in a way that is hardended, perhaps env vars?
I like the idea of a text file for these, rather than being embedded in the python source. Surely that can't be too hard? (Squishdot does this already for some things ;-) cheers, Chris
participants (3)
-
albert boulanger -
Chris Withers -
Dieter Maurer