A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2002-March/021842.html below:

R: [Python-Dev] Deprecating string exceptions

R: [Python-Dev] Deprecating string exceptionsGuido van Rossum guido@python.org
Thu, 28 Mar 2002 08:29:13 -0500
[me]
> Before we waste more time on this, let me explain why I like the rule
> that all exception classes be derived from Exception.  It's only a
> vague liking, and maybe it's not worth making it a rule.  I like it
> because including Exception (or one of its well-known subclasses) in
> the base class is a clue to the reader that a particular class
> declaration is used as an exception.  AFAIK this is the only reason
> why Java has a similar rule; C++ does not, and lets you throw any
> class.
> 
> I can't see any implementation benefits from the requirement.  It
> sounds like you can't either -- or else you would have pointed them
> out by now.  So maybe we shouldn't bother with this rule, and then we
> should take the recommendation out of the documentation.  But I still
> kind of like it, for the reason I explained in the previous paragraph.

One other, more practical reason to like the rule: "except Exception:"
would become equivalent to "except:".  The advantage is that you can
then write "except Exception, e:" and catch the exception instance in
a local variable without having to call sys.exc_info().

--Guido van Rossum (home page: http://www.python.org/~guido/)



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4