<div class="gmail_quote">On 16 September 2012 23:30, Cameron Simpson <span dir="ltr"><<a href="mailto:cs@zip.com.au" target="_blank">cs@zip.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 16Sep2012 13:16, Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>> wrote:<br>
| On 2012-09-15, at 10:20 PM, Cameron Simpson <<a href="mailto:cs@zip.com.au" target="_blank">cs@zip.com.au</a>> wrote:</div></blockquote><div><snip> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
| This thread started with IOError and its errno attribute, and for those<br>
| exact cases I find 'except .. if' approach quite useful. But now, in<br>
| 3.3 with PEP 3151 we have a much more granular exceptions tree, so instead<br>
| of writing<br>
|<br>
| except IOError as ex if ex.errno == errno.ENOENT:<br>
|<br>
| you will write:<br>
|<br>
| except FileNotFoundError as ex:<br>
|<br>
| And that's actually how this class of problems should be addressed:<br>
| instead of adding attributes to exceptions and exception guards to language -<br>
| just design your exception classes better.<br></div></blockquote><div> </div><div><snip> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OSErrno and IOError are generally built on low level OS APIs, and<br>
returning errno is a highly correct thing to do. It passes our, _with_ the<br>
exception (so it doesn't get maked by another library call, as the global<br>
POSIX error is subject to), the actual OS-level failure that was reported.<br>
<br>
Likewise with the S3 exceptions and probably any other well designed<br>
exception response to a library call with an informative failure code.</blockquote><div><br></div><div>"Informative" failure code? FileNotFoundError(...) contains *exactly* the same information as OSError(errno.ENOENT, ....). A number is not an informative error code, and never will be.</div>
<div><br></div><div>Additionally, I don't quite follow your first paragraph ("It passes our, _with_ the exception (so it doesn't get maked by another library call, as the global POSIX error is subject to),", but from what I can tell it seems extremely irrelevant to the end-programmer. I don't care what the OS-level failure is in terms of a number, I care in terms of the actual problem and what happened. It's not like we're receiving native data from the OS itself.</div>
<div><br></div><div>You have a point that error codes can be informative. They *can* be.</div><div>When you have a ValueError it could come from almost anywhere. However, it is a rare case for you to need to distinguish between these, and when you do it is normally for a reason specific enough that two subclasses can easily account for it all? I wouldn't mind (except that I mind being wrong :P) you showing me where you do have a sort of structure where you need to differentiate between many of the same error class yet cannot split it up, but until you do I don't believe that there's an analog case where this could help.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
| We have multiple inheritance after all, the perfect method of classifying<br>
| objects/exceptions, why should we code information about the exception class<br>
| to some attribute?<br>
| If some library unifies all types of exceptions in one 'S3ResponseError'<br>
| exception - that's the problem of the library design.<br>
<br>
</div>No, not necessarily. Having a ridiculous suite of a billion trite<br>
subclasses to enumerate the return codes from a lower level (or more<br>
"inner") library is just nuts.<br>
<br>
The PEP class tree is handy to _group_ an assortment of failure<br>
modes into small groups of the same flavour. But an exact one-to-one<br>
between exception subclasses and errno values? Ghastly. It _doubles_<br>
the cognitive burden on the dev and the code reader, because the<br>
correspondence between the OS-level errno and the subclass names needs to<br>
kept in mind if the program cares about the OS level failure mode. Which<br>
it does if it is bothering to make a fine grained decision at all.<br>
<br>
It is all very well to offer an, um, rich suite of subclasses representing<br>
various library failure modes. But to toss the _actual_ library failure<br>
indicator value in favour of a arbitrary and possibly incomplete class<br>
name list? Bad, really bad. The exception _should_ carry with it the<br>
underlying library failure code if the library has such a thing.<br></blockquote><div><br></div><div>As said above, how is Library.MathError(5) more arbitrary than Library.UncalculatableMathError()?</div><div><br></div><div>
If the number of errnos is large [n], then the cognitive burden is already large [n]. So if instead you have a large number [n] of error classes, how is the burden less [n == n]? It doesn't add any real effort on any side as you needed to allocate the numbers anyway, as you need to know the numbers.</div>
<div><br></div><div>Yes, if you have an incomplete name list you will suffer. But so what? Just cover all your bases. If you are wrapping a program from a lower-level language, wrap *everything you need*. It's no different to any other aspect of wrapping libraries.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
| Big -1.<br>
<br>
I'm not +1 any more, but still +.<br></blockquote><div><br></div><div>I'm negative, but not -1. The problem is: there are bad libraries. I think the stuff I mentioned already is a better solution though, and it seems it's not even my idea :). </div>
</div>