Unhide exceptions

[mottosso]

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.

root@4451f75afd4f:/# lsb_release -crd
# Description:    Ubuntu 18.04.4 LTS
# Release:        18.04
# Codename:       bionic

root@4451f75afd4f:/# pip install pyside2
# Collecting pyside2
#   Downloading https://files.pythonhosted.org/packages/d7/fd/8123071e83f37dfca90b6a14637bdf06940098eac25ffd854b59408d0d4e/PySide2-5.15.0-5.15.0-cp27-cp27mu-manylinux1_x86_64.whl (170.3MB)
#     100% |################################| 170.3MB 10kB/s
# Collecting shiboken2==5.15.0 (from pyside2)
#   Downloading https://files.pythonhosted.org/packages/99/75/5776ce883492a0040120979692899ec5b3ed1df48ecffac6f1b2722d329b/shiboken2-5.15.0-5.15.0-cp27-cp27mu-manylinux1_x86_64.whl (1.1MB)
#     100% |################################| 1.1MB 1.6MB/s
# Installing collected packages: shiboken2, pyside2
# Successfully installed pyside2-5.15.0 shiboken2-5.15.0

root@4451f75afd4f:/# pip install qt.py
# Collecting qt.py
#   Downloading https://files.pythonhosted.org/packages/54/91/904d6e768d04a2f15bcf941dca99d84e3e03fdc3969002236128164f5334/Qt.py-1.2.5-py2.py3-none-any.whl
# Installing collected packages: qt.py
# Successfully installed qt.py-1.2.5

root@4451f75afd4f:/# python
# Python 2.7.17 (default, Apr 15 2020, 17:20:14)
# [GCC 7.5.0] on linux2
# Type "help", "copyright", "credits" or "license" for more information.

>>> import Qt
# Traceback (most recent call last):
#   File "<stdin>", line 1, in <module>
#   File "/usr/local/lib/python2.7/dist-packages/Qt.py", line 1905, in <module>
#     _install()
#   File "/usr/local/lib/python2.7/dist-packages/Qt.py", line 1883, in _install
#     our_submodule = getattr(Qt, name)
# AttributeError: 'module' object has no attribute 'QtGui'

>>> import PySide2
>>> from PySide2 import QtGui
# Traceback (most recent call last):
#   File "<stdin>", line 1, in <module>
# ImportError: libGL.so.1: cannot open shared object file: No such file or directory

This is a ImportError about missing a OpenGL library masquerading as an AttributeError. 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.

>>> import Qt.py
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/Qt.py", line 1905, in <module>
    _install()
  File "/usr/local/lib/python2.7/dist-packages/Qt.py", line 1853, in _install
    raise ImportError("No Qt binding were found.")
ImportError: No Qt binding were found.

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..

ImportError: Qt.py tried finding PyQt5, PyQt4, PySide2 and PySide (in that order)
but wasn't able to, make sure at least one of them is available to the Python
interpreter currently running (i.e. /full/path/to/python)

I've never seen a too-verbose error message. In this case, it might even make sense to provide debugging hints.

To make sure, try calling `import PySide2.QtGui` yourself, or
any binding you expect to have installed, and make sure it
imports without error, that's more or less what Qt.py needs
to do.

Does this sound familiar? Have you encountered a non-sensical error message from Qt.py? Let me know here!

[justinfx]

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.