jamadden
commented
6 years ago I agree the tracebacks can be distracting. But the way the ConfigurationError exceptions just preserve the string or repr value of the underlying exception can also lose information. Instead of seeing the specific class of the exception (InvalidDottedName), you just tend to wind up with a bunch of context-less tuples of the arguments that don't tell you much (ConfigurationError: ('Invalid value for', 'class', '.systemerror.SystemErrorView') Is it invalid because it's not a class? It didn't pass some constraint? It doesn't exist?) And in the end, even that's getting lost here (the final report doesn't show that at all!)
If we could have a better way to preserve all the useful information from below I wouldn't be against trimming tracebacks. Maybe each 'except' could look for a ConfigurationError and just add its context info before reraising the same exception, and the repr for ConfigurationError would be smart enough to show all that. (So the subclass ZopeXMLConfigurationError would go away.)
(BTW, that InvalidDottedName should be fixed with 4.2.2 of this package.)
mgedmin
There were some recent zope.schema and/or zope.configuration releases that broke ZODBBrowser (and many other things). This bug is not about that. This bug is about error reporting on Python 3.
Here's the series of chained exception tracebacks I get on Python 3.6 when there's an error in a ZCML file (included from a sequence of other ZCML files):
It looks like every include adds a new exception (with full traceback) to the chain.
Can we use
raise ... from Noneto disable chaining so there's only one traceback in the end?