[Python-ideas] Consistent programming error handling idiom

[Steven D'Aprano]

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?


-- 
Steve