raise None
Christian Gollwitzer
auriocus at gmx.de
Mon Jan 4 02:28:44 EST 2016
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
More information about the Python-list
mailing list