Guido van Rossum wrote: > ValueError is > typically a bug in the immediate code containing the call.
Not necessarily, because the value may have been stored somewhere for a while before being used. > IOError is > something that could happen even to valid calls (e.g. when a library > is passed a stream that happens to have been put in nonblocking mode; But the calling code has made a mistake by passing such a stream to the library in the first place. > if the library has a recovery for other I/O errors like disk full or > broken connections, the recovery should be applied in this case, too). I don't see how. For something like "Disk full", the library can report it to the application, and the application can notify the user and tell him to make more room somehow. But how can the application recover from trying to use a non-blocking socket inappropriately? It's not the user's fault, and there's nothing the user can to do fix it. I'd much rather the whole EnvironmentError subtree were reserved for external things that the user can do something about. That way the application can easily sort out what should be reported as a user error, and what should be reported as a program bug. I realise this isn't quite true at the moment, because things like passing invalid parameters to a system call will probably produce an IOError or OSError. But there's no sense in muddying things any further if it can be easily avoided. -- Greg _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
