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. -- https://mail.python.org/mailman/listinfo/python-list
