[python-users] Python3 - Exception-Context überschreiben/raise from - gut oder schlecht?

[Daniel Hepper]

Hallo Till,

das Argument dass der Stacktrace aus der Library nicht Teil der API sein
soll finde ich nicht sehr gehaltvoll. Natürlich könnte jemand auf die Idee
kommen irgendwie den Stacktrace zu parsen, aber wenn das dann unweigerlich
kaputt geht ist der derjenige definitiv selbst Schuld.

Nach meiner Erfahrung sind alle Maßnahmen die im Fehlerfall den Kontext
reduzieren exzellent dazu geeignet sich beim Debugging das Leben schwer zu
machen.

Der vollständige Stacktrace ist natürlich für einen nicht-technischen
Endanwender wenig hilfreich und im Falle einer Web-Applikation ggf. sogar
ein Sicherheitsrisiko. Für's Debugging ist er aber unentbehrlich und sollte
deshalb wenn immer möglich festgehalten werden.

Die String-Respräsentation einer Exception ist normalerweise nur die
Message, und die ist manchmal erstaunlich wenig aussagekräftig. Ein kleines
Beispiel:

try:
    d = {}
    print(d['x'])
except Exception as e:
     logger.error('An error occurred: %s', e)

Output: 'An error occurred: x'

Good luck with that!

Von meiner Seite deshalb ein klares -1 für raise from None.

Grüße,
Daniel


On Wed, Apr 17, 2019 at 1:17 PM Till Maas <opensource at till.name> wrote:

> Hi,
>
> in einem Python-Projekt an dem ich mitwirke ist aufgefallen, dass der
> Default-Python3-Exception-Handler bei Ketten von Exceptions ausgibt,
> welche Exceptions zuvor aufgetreten sind, Beispiel:
>
> Traceback (most recent call last):
>   File "/home/fge/Source/nmstate/libnmstate/nm/checkpoint.py", line 125,
> in destroy
>     self._manager.interface.CheckpointDestroy(self._dbuspath)
>   File "/usr/lib64/python3.7/site-packages/dbus/proxies.py", line 70, in
> __call__
>     return self._proxy_method(*args, **keywords)
>   File "/usr/lib64/python3.7/site-packages/dbus/proxies.py", line 145, in
> __call__
>     **keywords)
>   File "/usr/lib64/python3.7/site-packages/dbus/connection.py", line 651,
> in call_blocking
>     message, timeout)
> dbus.exceptions.DBusException:
> org.freedesktop.NetworkManager.InvalidArguments: checkpoint
> /org/freedesktop/NetworkManager/Checkpoint/7 does not exist
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/home/fge/Source/nmstate/libnmstate/netapplier.py", line 72, in
> commit
>     nmcheckpoint.destroy()
>   File "/home/fge/Source/nmstate/libnmstate/nm/checkpoint.py", line 127,
> in destroy
>     raise NMCheckPointError(str(e))
> libnmstate.nm.checkpoint.NMCheckPointError:
> org.freedesktop.NetworkManager.InvalidArguments: checkpoint
> /org/freedesktop/NetworkManager/Checkpoint/7 does not exist
>
>
> Für mich sieht das sehr nützlich aus. Mein Mitstreiter hat allerdings
> Bedenken, weil dies ja interne Details ausgibt (statt nur der Exception,
> die Teil der API ist) und schlägt vor, die zu unterbinden mit
>
> raise from None
>
> Was sind Eure Erfahrungen/Meinungen dazu? Ist `raise from None` sinnvoll
> oder nicht? Ich habe eher das Gefühl, dass nicht.
>
> Falles es Euch interessiert, Details gibt es hier:
> https://github.com/nmstate/nmstate/pull/317#issuecomment-483901082
>
> Viele Grüße
> Till
> ________________________________________
>
> Diese Mail erhalten Sie ueber die Mailingliste python-users der
> Universitaet zu Koeln
> Nachrichten an: python-users at uni-koeln.de
> Abonnement und Benutzereinstellungen:
> https://lists.uni-koeln.de/mailman/listinfo/python-users
> Listenarchiv: https://lists.uni-koeln.de/pipermail/python-users/
>
> pyCologne Homepage: http://pycologne.de/
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-koeln.de/pipermail/python-users/attachments/20190417/f34c4ca8/attachment.html>