Movatterモバイル変換
[0]ホーム
[Python-Dev] Exception Reorg PEP revised yet again
Nick Coghlanncoghlan at gmail.com
Tue Aug 9 12:30:03 CEST 2005
Raymond Hettinger wrote:> TerminatingException> -------------------->> The rationale for adding TerminatingException needs to be developed or> reconsidered. AFAICT, there hasn't been an exploration of existing code> bases to determine that there is going to be even minimal use of "except> TerminatingException".>> Are KeyboardInterrupt and SystemExit often caught together on the same> line and handled in the same way?Yes, to avoid the current overbroad inheritance of "except Exception:" by intercepting and reraising these two terminating exceptions.> If so, isn't "except TerminatingException" less explicit, clear, and> flexible than "except (KeyboardInterrupt, SystemExit)"?No, TerminatingException makes it explicit to the reader what is going on - special handling is being applied to any exceptions that indicate the interpreter is expected to exit as a result of the exception. Using "except (KeyboardInterrupt, SystemExit):" is less explicit, as it relies on the reader knowing that these two exceptions share the common characteristic that they are generally meant to terminate the Python interpreter.> Are there any benefits sufficient to warrant yet another new built-in?> Does it also warrant violating FIBTN by introducing more structure?> While I'm clear on why KeyboardInterrupt and SystemExit were moved from> under Exception, it is not at all clear what problem is being solved by> adding a new intermediate grouping.The main benefits of TerminatingException lie in easing the transition to Py3k. After transition, "except Exception:" will already do the right thing.However, TerminatingException will still serve a useful documentational purpose, as it sums up in two words the key characteristic that caused KeyboardInterrupt and SystemExit to be moved out from underneath Exception.> Bare excepts defaulting to Exception> ------------------------------------>> After further thought, I'm not as sure about this one and whether it is> workable. The code fragment above highlights the issue. In a series of> except clauses, each line only matches what was not caught by a previous> clause. This is a useful and basic part of the syntax. It leaves a> bare except to have the role of a final catchall (much like a default in> C's switch-case). If one line uses "except Exception", then a> subsequence bare except should probably catch KeyboardInterrupt and> SystemExit. Otherwise, there is a risk of creating optical illusion> errors (code that looks like it should work but is actually broken).> I'm not certain on this one, but the PEP does need to fully explore the> implications and think-out the consequent usability issues.I'm also concerned about this one. IMO, bare excepts in Python 3k should either not be allowed at all (use "except BaseException:" intead), or they should be synonyms for "except BaseException:".Having a bare except that doesn't actually catch everything just seems wrong - and we already have style guides that say "except Exception:" is to be generally preferred over a bare except. Consenting adults and all that. . .Cheers,Nick.-- Nick Coghlan |ncoghlan at gmail.com | Brisbane, Australia---------------------------------------------------------------http://boredomandlaziness.blogspot.com
More information about the Python-Devmailing list
[8]ページ先頭