Am 31.12.15 um 16:35 schrieb Steven D'Aprano:
But I think it is a real issue. I believe in beautiful tracebacks that give
you just the right amount of information, neither too little nor two much.
Debugging is hard enough with being given more information than you need
and having to decide what bits to ignore and which are important.
>
The principle is that errors should be raised as close to their cause as
possible. If I call spam(a, b) and provide bad arguments, the earliest I
can possibly detect that is in spam. (Only spam knows what it accepts as
arguments.) Any additional levels beyond spam (like _validate) is moving
further away:
File "spam", line 19, in this
File "spam", line 29, in that <--- where the error really lies
File "spam", line 39, in other
File "spam", line 89, in spam <--- the first place we could detect it
File "spam", line 5, in _validate <--- where we actually detect it
As a side note, this problem is solved by an enhanced return statement
in Tcl. Translating the syntax to Python, it would read something like:
def validate(a,b):
if a>b:
return(SomeError, code=error, level=1)
"raise SomeError" would be identical to "return(SomeError, code=error,
level=0)". In general you can return codes for continue, break and
return to have the upper level act as if continue, break or raise was
executed at the point where the function was called.
Christian
--
https://mail.python.org/mailman/listinfo/python-list
