Open mottosso opened 4 years ago
I support your idea to make error messages more verbose. As you pointed out, this project is only a helper and not the binding layer. It does a lot of magic to try and find the best bindings match at import time, so the more information that can be provided about the failure, the easier it will be to figure out the underlying cause.
One idea I thought about while patching #342 was to maybe accumulate the errors in a list until we reach a fatal point like the attribute error, and can log them all out before failing. This would be a different approach vs how my fix was immediately logging the unexpected import error types, and then it happens to fail later.
Qt.py hides many exceptions in an effort to make using it more pleasant. But it's too aggressive. Hiding things like #342 just now, and also this.
This is a
ImportError
about missing a OpenGL library masquerading as anAttributeError
. Had you seen the true error could you rectify it (by installing display drivers in this case, running in an empty Docker container). But what you would see is something that makes no sense. Did this version of PySide2 not provide the QtGui submodule? That was my first thought. An incomplete binding.On the flipside, here's an example of a successful handling.
It's clear and to the point, however, I've seen this message stump developers thinking that Qt.py is the binding. And how can you blame them? You
import Qt
and that's what you work with. Not everyone has had the (mis)fortune of having worked with PySide/PyQt before or know about any need for supporting all of them at once via a "shim" like Qt.py.The message could instead have read..
I've never seen a too-verbose error message. In this case, it might even make sense to provide debugging hints.
Does this sound familiar? Have you encountered a non-sensical error message from Qt.py? Let me know here!