[Python-Dev] PEP 342 support for string exceptions in throw()

[Phillip J. Eby]

At 03:23 PM 3/24/2006 -0800, Guido van Rossum wrote:
>And I see no reason to complicate the code with an additional check
>that doesn't serve a purpose. The purpose of reminding people not to
>write g.throw("abc") seems artificial to me. I'd rather see less code,
>meaning less maintenance, and no need to remove the check later

I think you're still thinking as though there was support, and I'm 
proposing adding new code to restrict the support.  There is *no* support 
for string exceptions now, so we are going to be adding code, period.  :)

For comparison purposes, here is the patch for doing it my way:

Index: Objects/genobject.c
===================================================================
--- Objects/genobject.c (revision 43297)
+++ Objects/genobject.c (working copy)
@@ -249,7 +249,10 @@
                         Py_INCREF(typ);
                 }
         }
-       else {
+
+       /* Allow reraise of builtin string exceptions if traceback was given */
+
+       else if (!PyString_CheckExact(typ) || !tb) {
                 /* Not something you can raise.  throw() fails. */
                 PyErr_Format(PyExc_TypeError,
                              "exceptions must be classes, or instances, 
not %s",

And now, here's the patch for doing it your way:

Index: Objects/genobject.c
===================================================================
--- Objects/genobject.c (revision 43297)
+++ Objects/genobject.c (working copy)
@@ -249,7 +249,10 @@
                         Py_INCREF(typ);
                 }
         }
-       else {
+
+       /* Allow raising builtin string exceptions */
+
+       else if (!PyString_CheckExact(typ)) {
                 /* Not something you can raise.  throw() fails. */
                 PyErr_Format(PyExc_TypeError,
                              "exceptions must be classes, or instances, 
not %s",


As you can see, there are only a few characters difference between the two, 
so I'm not sure there's a significant maintenance overhead involved either 
way.  Indeed, we've probably used more time discussing it than will ever be 
spent maintaining it.  :)


>  (or
>when I merge your changes into the p3yk branch).

Actually, you won't need to merge them if Python 3000 doesn't support 
string exceptions.  The code you've already got should be correct for that, 
because again, there is *no* support for string exceptions in the trunk 
right now.