Movatterモバイル変換
[0]ホーム
[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Stephen J. Turnbullstephen at xemacs.org
Tue Aug 2 09:13:10 CEST 2005
>>>>> "Phillip" == Phillip J Eby <pje at telecommunity.com> writes: Phillip> You just said, "Unhandled, KeyboardInterrupt means..." Phillip> If the program doesn't *want* to handle Phillip> KeyboardInterrupt, then it obviously *isn't* critical, Phillip> because it doesn't care. Conversely, if it *does* handle Phillip> KeyboardInterrupt, then once again, it's not critical by Phillip> your definition.That's not my definition. By that argument, no condition that can behandled can be critical.By my definition, the condition only needs to prevent the program fromcontinuing normally when it arises. KeyboardInterrupt is a conventionthat is used to tell a program that continuing normally is notacceptable behavior, and therefore "critical" by my definition.Under either definition, we'll still need to do something special withMemoryError, KeyboardInterrupt, et amicae, and they still shouldn't becaught by a generic "except Exception". We agree on that, don't we? Phillip> Note, by the way, that Python programs can disable a Phillip> KeyboardInterrupt [...]. Ergo, it's a control flow Phillip> exception.Sure, in some sense---but not in the Python language AFAIK. Whichcontrol constructs in the Python language define semantics forcontinuation after KeyboardInterrupt occurs? Anything that can stop aprogram but the language doesn't define semantics for continuation iscritical and exceptional by my definition. Willem> I'd prefer the 'condition' and 'error' terminology, and to Willem> label a keyboard interrupt a condition, not any kind of Willem> exception or error. >> Now, that does bother me.<wink> [...] Phillip> On the contrary, it is control-flow exceptions that bare Phillip> except clauses are most harmful to: StopIteration, Phillip> SystemExit, and... you guessed it... KeyboardInterrupt.That is a Python semantics issue, but as far as I can see there'sunanimity on it. I and (AFAICS) Willem were discussing theconnotations of the _names_ at this point, and whether they weresuggestive of the semantics we (all!) seem to agree on. I do not findthe word "condition" suggestive of the "things 'bare except' shouldnot catch" semantics. I believe enough others will agree with me thatthe word "condition", even "serious condition", should be avoided. Phillip> An exception that's being used for control flow is Phillip> precisely the kind of thing you don't want anything but Phillip> an explicit except clause to catch.Which is exactly the conclusion I reached: [It] makes me wonder if there's any benefit to having a class [ie, CriticalException] between Raisable and KeyboardInterrupt. ...I don't see a need for a class whose members share only the property that they are not catchable with a bare except....Now, somebody proposed:Raisable -+- Exception +- ... +- ControlFlowException -+- StopIteration +- KeyboardInterruptAs I wrote above, I see no use for that; I think that's what you'resaying too, right? AIUI, you wantRaisable -+- Exception +- ... +- StopIteration +- KeyboardInterruptso that only the appropriate control construct or an explicit exceptcan catch a control flow exception. At least, you've convinced methat "critical exception" is not a concept that should be implementedin the Python language specification. Rather, (for those who think asI do, if there are others<wink>) "critical exception" would be anintuitive guide to a subclass of exceptions that shouldn't be caughtby a bare except (or a handler for any superclass except Raisable, forthat matter).By the same token, "control flow exception" is a pedagogical concept,not something that should be reified in a ControlFlowException class,right? Phillip> If you think that a KeyboardInterrupt is an error,I have used the word "error" only in quoting Willem, and that's quitedeliberate. I don't think that a condition need be an error to be"critical".-- School of Systems and Information Engineeringhttp://turnbull.sk.tsukuba.ac.jpUniversity of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
More information about the Python-Devmailing list
[8]ページ先頭