On Thu, 31 Dec 2015 12:44 pm, Ben Finney wrote: > Steven D'Aprano <st...@pearwood.info> writes: > >> Traceback (most recent call last): >> File "spam", line 19, in this >> File "spam", line 29, in that >> File "spam", line 39, in other >> File "spam", line 5, in _validate >> ThingyError: ... >> >> and the reader has to understand the internal workings of _validate >> sufficiently to infer that this exception is not a bug in _validate >> but an expected failure mode of other when you pass a bad argument. > > This point seems to advocate for suppressing *any* code that > deliberately raises an exception. Is that your intent?
No. The issue isn't that an exception is deliberately raised. The issue is that it is deliberately raised in a function separate from where the exception conceptually belongs. The exception is conceptually part of function "other", and was only refactored into a separate function _validate to avoid repeating the same validation code in multiple places. It is a mere implementation detail that the exception is actually raised inside _validate rather than other. As an implementation detail, exposing it to the user (in the form of a line in the stacktrace) doesn't help debugging. At best it is neutral (the user reads the error message and immediately realises that the problem lies with bad arguments passed to other, and _validate has nothing to do with it). At worst it actively misleads the user into thinking that there is a bug in _validate. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
