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/2000-December/010941.html below:

[Python-Dev] Warning Framework (PEP 230)

[Python-Dev] Warning Framework (PEP 230)Guido van Rossum guido@python.org
Mon, 11 Dec 2000 13:16:58 -0500
> > > How about returning 1 for 'warning turned into exception' and -1 for 'normal
> > > exception' ? It would be slightly more similar to other functions if '-1'
> > > meant 'exception', and it would be easy to put in an if statement -- and
> > > still allow C code to ignore the produced error, if it wanted to.
> 
> > Why would you want this?  The user clearly said that they wanted the
> > exception!
> 
> The difference is that in one case, the user will see the original
> warning-turned-exception, and in the other she won't -- the warning will be
> lost. At best she'll see (by looking at the traceback) the code intended to
> give a warning (that might or might not have been turned into an exception)
> and failed.

Yes -- this is a standard convention in Python.  if there's a bug in
code that is used to raise or handle an exception, you get a traceback
from that bug.

> The warning code might decide to do something aditional to
> notify the user of the thing it intended to warn about, which ended up as a
> 'real' exception because of something else.

Nah.  The warning code shouldn't worry about that.  If there's a bug
in PyErr_Warn(), that should get top priority until it's fixed.

--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