[Python-ideas] Consistent programming error handling idiom
steve at pearwood.info
Sun Apr 10 12:39:24 EDT 2016
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
> 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
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
That's ... rather strange. As in:
EnvironmentError("substring not found")
for an unsuccessful search?
More information about the Python-ideas