https://bugs.freedesktop.org/show_bug.cgi?id=66025
--- Comment #45 from David Bolen <[email protected]> --- Created attachment 83056 --> https://bugs.freedesktop.org/attachment.cgi?id=83056&action=edit Final patch Ok, let's see if we can't close this out. The attached is a (hopefully) final patch. I will also be attaching some updated samples of before and after tracebacks. This patch incorporates a full traceback, with an ImportError always of the form "ImportError: XXX (or YYY)" where XXX is the original Python exception text, and YYY is the name uno tried to resolve after the Python exception. I've run this by Tim independently, and I believe it now fully satisfies his original problem case where his import issue was completely obscured by uno (my other attachment will include tracebacks from his testing). On the back-port question, I don't know if there are any guidelines for what qualifies or not. Technically this behavior (obscuring the underlying failure) has been around for a really long time (including in 3.x) so it's not a new bug or regression. With that said, I think the new behavior is a real improvement for problem diagnosis in the nested import case. As written it is compatible with any 4.x series, and can even apply to 3.x with minor changes, though I suspect it's not worth the hassle to go back further than 4.1. A few other details, mostly for the bug record: The patch provides inclusion of the full traceback (so you'll always see the actual line of the failure) and for the exception text, combines the original Python text with the first uno lookup error. The "first" part is important since the uno code will perform additional lookups higher up the import nesting chain on an error and the uno failure would be out of sync with the traceback if the failure was in a nested module. As this is still a mash-up of two possibilities (a python import issue versus an uno lookup problem) the exception is of necessity more ambiguous, and sub-optimal in some cases (which I can't see any way to resolve without an unambiguous way to identify uno modules/namespaces): 1. The full traceback includes all uno_import frames, so there will be a number of _g_delegatee entries that are potentially confusing and cannot be avoided. But on balance you get to see the actual point of failure, even for uno issues occurring in a nested module, where previously all you saw was the highest level "from x import y" that uno processed. 2. For a python exception, the uno reference is going to be unnecessary and could be potentially confusing. No real way to avoid this however, since the original python exception is often useless for uno diagnostics (see next point). 3. For an uno issue, the import processing walks the module hierarchy so for example "from com.sun.star.style import foo" will attempt to import com.sun.star.style, com.sun.star, com.sun and com. This isn't an issue if foo is found, but if not, in Python 3 the exception will have _g_delegatee traceback frames for each nested (missing) module, and the failure cause will be the uppermost com module. Point (3) means that most usual uno issues now have an exception of the form "ImportError: No module named 'com' (or YYY)" where YYY is the real problem. (This is a change from Python 2 was where it would show the full com.sun.star.style in such an exception). So the com reference may be confusing as it never actually exists. I debated flipping XXX and YYY in the exception message for this reason, since arguably importing uno could be an implicit acceptance of wanting to see uno-related errors primarily. But I feel that it is more defensible to keep the actual Python exception as the base and augment with uno, especially since importing uno is going to affect all import errors across a code base (at least using from x import y) - OpenLP being a good example. I also debated doing special processing in the "com" case to adjust the message (since even if not the exclusive namespace for uno, seems likely to be the most heavily used), but opted against it as not being worth the additional logic. It does mean you'll probably need to always ignore the first part of the exception message in an uno issue, but the YYY is the same as that currently shown (or even more accurate, in a nested case) so I don't think it's much of a hardship. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
