[Python-ideas] Consistent programming error handling idiom

[Greg Ewing]

Steven D'Aprano wrote:
> 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.

Of course you can't assume that an EnvironmentError
*anywhere* in the program represents a user error.
I was just suggesting a heuristic for the *top level*
exception hander to use.

Making that heuristic work well requires cooperation
from the rest of the code. In this case, it means
wrapping the code that reads config files to catch
file-not-found errors. You're going to have to do
that anyway if you want to carry on with the rest of
the processing.

> That's ... rather strange. As in:
> 
> EnvironmentError("substring not found")
> 
> for an unsuccessful search?

I might put a bit more information in there to help
the user.

The idea is that whatever I put in the EnvironmentError
will end up getting displayed to the user as an error
message by my top-level exception handler.

I might also use a subclass of EnvironmentError if I
want to be able to catch it specifically, but that's
not strictly necessary. I don't show the user the
exception class name, only its argument.

-- 
Greg