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.