PEP 678: Enriching Exceptions with Notes

@notatallshaw, yep, that was me - I’ll add a link to that discussion in the PEP.

@barry, the idiom here would be to raise an ExceptionGroup where the inner exceptions had notes “First attempt to commit this change”, “Second attempt…”, and so on.

The attempt count can be tracked as a local variable, or if you want to use it elsewhere you can assign to e.g. an err._n_attempted_commits = 7 attribute on the exception object and avoid parsing!

@mattip, avoiding the risk of delayed formatting errors is another good reason to insist that __note__ must be a string or None! This doesn’t introduce any additional concerns about format strings, because the formatting of the note itself must be finalised before it can be added to the exception, and the traceback code only needs to deal with string as format arguments (which is safe).

The runtime cost amounts to an attribute assignment and typecheck if a note is assigned, and one branch in the traceback display code to show it. This is pretty cheap.

My personal motivation for writing this PEP was that I found it was impossible to support satisfactory error reporting in Hypothesis with ExceptionGroup. Each exception has additional data (such as the minimal failing example), which should remain closely associated. Currently we just print this information and each respective traceback before raising a MultipleFailures exception, but printing some data and then raising an ExceptionGroup splits up the relevant logs even if none of the inner exceptions are handled without being displayed to the user.

I would like backports.exceptiongroup to display __note__ for inner exceptions, but to display at all this has to be part of the exceptiongroup class or traceback-printing code. The latter seems much more elegant to me, and thus this PEP.

3 Likes