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