On Sun, Apr 10, 2016 at 05:38:41PM +1200, Greg Ewing wrote:
Rian Hunter wrote:
I want a consistent opt-in idiom with community consensus. I want a clear way to express that an exception is an error and not an internal bug.
There's already a convention for this. Exceptions derived from EnvironmentError (OSError in python 3) usually result from something the user did wrong. Anything else that escapes lower-level exception handling is probably a bug.
I don't think this is a valid description of EnvironmentError. I don't think you can legitimately say it "usually" comes from user error.
Let's say I have an application which, on startup, looks for config files in various places. If they exist and are readable, the application uses them. If they don't exist or aren't readable, an EnvironmentError will be generated (say, IOError). This isn't a user error, and my app can and should just ignore such missing config files.
Then the application goes to open a user-specified data file. If the file doesn't exist, or can't be read, that will generate an EnvironmentError, but it isn't one that should be logged. (Who wants to log every time the user mispells a file name, or tries to open a file they don't have permission for?)
In an interactive application, the app should display an error message and then wait for more commands. In a batch or command-line app, the application should exit. So treatment of the error depends on *what sort of application* you have, not just the error itself.
Then the application phones home, looking for updates to download, uploading the popularity statistics of the most commonly used commands, bug reports, etc. What if it can't contact the home server? That's most likely an EnvironmentError too, but it's not a user-error.
Oops, I spelled the URL of my server "http://myserver.com.ua" instead of .au. So that specific EnvironmentError is a programming bug. (No wonder I haven't had any popularity stats uploaded...)
So EnvironmentError can represent any of:
- situation normal, not actually an error at all; - a non-fatal user-error; - a fatal user-error; - transient network errors that will go away on their own; - programming bugs.
It's not perfect, but it works well enough most of the time. If I find a case where some non-bug exception gets raised that doesn't derive from EnvironmentError, I fix things so that it gets caught somewhere lower down and re-raised as an EnvironmentError.
That's ... rather strange. As in:
EnvironmentError("substring not found")
for an unsuccessful search?