The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Michael Torrie]

On 03/22/2016 06:59 AM, BartC wrote:
> I'm not sure I follow. Your solution to dealing with the scenarios 
> raised by Steven D'Aprano is to:
> 
> (1) Not bother with exceptions at all inside the function

Correct, if your function is not equipped to handle this exceptional
circumstance and do the right thing, the right thing to do is let the
caller deal with it.  Otherwise debugging is very hard if not
impossible.  In your former example, a 0 return code means what exactly?
File not found? File exists but permission is denied?
> 
> (2) Not bother with them in the user code either

Again, it depends on whether the user code is equipped to react to the
exception and do the right thing.  I probably would catch file and i/o
errors like file-not-found and print a specific message out (or a dialog
box).  Or loop back to try again if the user was picking a file to work
with.

And despite the impression you may have gotten, it is appropriate to
look before you leap. Using os.exists() and other pre-flight checks are
appropriate.

> (3) Let any errors just crash out (raise a Python system error) (just 
> like I did in my original jpeg program which I was called out on)

Any exceptions your program is not explicitly equipped to deal with
should indeed bubble up to the OS and crash out.  After all it's by
definition an exceptional event and the state of your program and data
after this point is not reliable if such an event is ignored.  And it
provides valuable information an end user can pass back to you as a
developer to find bugs you missed.

> (4) Or if the user code does want to check for certain errors (like, 
> File Not Found, by far the most likely, and so that it can deal with 
> that and continue executing), it now has to go and dig out docs for ... 
> what? The user code needs to know what is going on inside the supposedly 
> opaque function it's calling.

Good documentation should describe exactly what exceptions a function or
library raises and why.  I tend to try to follow the example of Python's
standard library. I keep my exception classes few, and raise a good
error message with it.

But often times the exceptions we're talking about are standard Python
exceptions arising from things like I/O, not custom library classes.