[Python-ideas] [Python-Dev] OSError.errno => exception hierarchy?
Gustavo Carneiro
gjcarneiro at gmail.com
Fri Apr 3 01:13:05 CEST 2009
(cross-posting back to python-dev to finalize discussions)
2009/4/2 Guido van Rossum <guido at python.org>
[...]
> > The problem you report:
> >>
> >> try:
> >> ...
> >> except OSWinError:
> >> ...
> >> except OSLinError:
> >> ...
> >>
> >
> > Would be solved if both OSWinError and OSLinError were always defined in
> > both Linux and Windows Python. Programs could be written to catch both
> > OSWinError and OSLinError, except that on Linux OSWinError would never
> > actually be raised, and on Windows OSLinError would never occur. Problem
> > solved.
>
> Yeah, but now you'd have to generate the list of exceptions (which
> would be enormously long) based on the union of all errno codes in the
> universe.
>
> Unless you only want to do it for some errno codes and not for others,
> which sounds like asking for trouble.
>
> Also you need a naming scheme that works for all errnos and doesn't
> require manual work. Frankly, the only scheme that I can think of that
> could be automated would be something like OSError_ENAME.
>
> And, while OSError is built-in, I think these exceptions (because
> there are so many) should not be built-in, and probably not even live
> in the 'os' namespace -- the best place for them would be the errno
> module, so errno.OSError_ENAME.
>
> > The downsides of this? I can only see memory, at the moment, but I might
> be
> > missing something.
>
> It's an enormous amount of work to make it happen across all
> platforms. And it doesn't really solve an important problem.
I partially agree. It will be a lot of work. I think the problem is valid,
although not very important, I agree.
>
>
> > Now just one final word why I think this matters. The currently correct
> way
> > to remove a directory tree and only ignore the error "it does not exist"
> is:
> >
> > try:
> > shutil.rmtree("dirname")
> > except OSError, e:
> > if errno.errorcode[e.errno] != 'ENOENT':
> > raise
> >
> > However, only very experienced programmers will know to write that
> correct
> > code (apparently I am not experienced enought!).
>
> That doesn't strike me as correct at all, since it doesn't distinguish
> between ENOENT being raised for some file deep down in the tree vs.
> the root not existing. (This could happen if after you did
> os.listdir() some other process deleted some file.)
OK. Maybe in a generic case this could happen, although I'm sure this won't
happen in my particular scenario. This is about a build system, and I am
assuming there are no two concurrent builds (or else a lot of other things
would fail anyway).
> A better way might be
>
> try:
> shutil.rmtree(<dir>)
> except OSError:
> if os.path.exists(<dir>):
> raise
Sure, this works, but at the cost of an extra system call. I think it's
more elegant to check the errno (assuming the corner case you pointed out
above is not an issue).
> Though I don't know what you wish to happen of <dir> were a dangling
> symlink.
>
> > What I am proposing is that the simpler correct code would be something
> > like:
> >
> > try:
> > shutil.rmtree("dirname")
> > except OSNoEntryError:
> > pass
> >
> > Much simpler, no?
>
> And wrong.
>
> > Right now, developers are tempted to write code like:
> >
> > shutil.rmtree("dirname", ignore_errors=True)
> >
> > Or:
> >
> > try:
> > shutil.rmtree("dirname")
> > except OSError:
> > pass
> >
> > Both of which follow the error hiding anti-pattern [1].
> >
> > [1] http://en.wikipedia.org/wiki/Error_hiding
> >
> > Thanks for reading this far.
>
> Thanks for not wasting any more of my time.
OK, I won't waste more time. If this were an obvious improvement beyond
doubt to most people, I would pursue it, but since it's not, I can live with
it.
Thanks anyway,
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090403/5db48395/attachment.html>
More information about the Python-ideas
mailing list