Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder3.xlned.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CAFEv2m6DdXK-c1YLn+6D5E1RHZ+p-AQ=2eqEh7c6Ls61+=ZAhQ@mail.gmail.com>
References: <CAN1F8qXPEM4B=2e7KOhWeTKzxmeeb_w_S97wYiHCMXH3jfzL6g@mail.gmail.com> <CAFEv2m6DdXK-c1YLn+6D5E1RHZ+p-AQ=2eqEh7c6Ls61+=ZAhQ@mail.gmail.com>
From: Joshua Landau <joshua.landau.ws@gmail.com>
Date: Wed, 29 May 2013 14:02:54 +0100
Subject: Re: Fatal Python error
To: Marcel Rodrigues <marcelgmr@gmail.com>
Content-Type: multipart/alternative; boundary=089e0118329a72723504dddb028c
Cc: python-list <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2355.1369832617.3114.python-list@python.org>
Lines: 99
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:46375

--089e0118329a72723504dddb028c
Content-Type: text/plain; charset=ISO-8859-1

On 29 May 2013 13:30, Marcel Rodrigues <marcelgmr@gmail.com> wrote:
>
> I just tried your code with similar results: it does nothing on PyPy
2.0.0-beta2 and Python 2.7.4. But on Python 3.3.1 it caused core dump.
> It's a little weird but so is the code. You have defined a function that
calls itself unconditionally. This will cause a stack overflow, which is a
RuntimeError.


The weirdness of the code is simply as I've taken all the logic and
conditionality away, since it was irrelevant. Why, though, does removing
any one element make it fail properly? That's what's confusing, largely.

>
>  Since you are handling this very exception with a pass statement, we
would expect that no error occurs. But the fatal error message seems pretty
informative at this point: "Cannot recover from stack overflow.".
>
> One thing to note is that while it's reasonable to handle exceptions that
happens at the level of your Python code, like a ValueError, it's not so
reasonable to try to handle something that may disturb the interpreter
itself in a lower level, like a stack overflow (I think that the stack used
by your code is the same stack used by the interpreter code, but I'm not
sure).


What is the expected response here then? Should I ever feel justified in
catching a Stack Overflow error? This code was extracted from a file
manager after much difficulty, but it should have been "caught" by a global
try...except and not crashed the whole program immediately. I'd imagine
that's a good enough reason to bring this up.



Also;
This works for the code:

def loop():
    thingwithproperty.prop
    loop()

This does not:

def loop():
    try:
        thingwithproperty.prop
    except:
        pass
loop()

thingwithproperty.prop NEVER creates an error.
(.prop is the new .property)

--089e0118329a72723504dddb028c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 29 May 2013 13:30, Marcel Rodrigues &lt;<a href=3D"mail=
to:marcelgmr@gmail.com">marcelgmr@gmail.com</a>&gt; wrote:<br>&gt;<br>&gt; =
I just tried your code with similar results: it does nothing on PyPy 2.0.0-=
beta2 and Python 2.7.4. But on Python 3.3.1 it caused core dump.<br>

&gt; It&#39;s a little weird but so is the code. You have defined a functio=
n that calls itself unconditionally. This will cause a stack overflow, whic=
h is a RuntimeError.<br><br><br>The weirdness of the code is simply as I=
9;ve taken all the logic and conditionality away, since it was irrelevant. =
Why, though, does removing any one element make it fail properly? That&#39;=
s what&#39;s confusing, largely.<br>

=A0<br>&gt;<br>&gt; =A0Since you are handling this very exception with a pa=
ss statement, we would expect that no error occurs. But the fatal error mes=
sage seems pretty informative at this point: &quot;Cannot recover from stac=
k overflow.&quot;.<br>

&gt;<br>&gt; One thing to note is that while it&#39;s reasonable to handle =
exceptions that happens at the level of your Python code, like a ValueError=
, it&#39;s not so reasonable to try to handle something that may disturb th=
e interpreter itself in a lower level, like a stack overflow (I think that =
the stack used by your code is the same stack used by the interpreter code,=
 but I&#39;m not sure).<br>

<br><br>What is the expected response here then? Should I ever feel justifi=
ed in catching a Stack Overflow error? This code was extracted from a file =
manager after much difficulty, but it should have been &quot;caught&quot; b=
y a global try...except and not crashed the whole program immediately. I=
9;d imagine that&#39;s a good enough reason to bring this up.<br>

<br><br><br>Also;<br>This works for the code:<br><br>def loop():<br>=A0 =A0=
 thingwithproperty.prop<br>=A0 =A0=A0loop()<br><br>This does not:<br><br>de=
f loop():<br>=A0 =A0 try:<br>=A0 =A0=A0=A0 =A0=A0thingwithproperty.prop<br>=
=A0 =A0=A0except:<br>=A0 =A0=A0=A0 =A0=A0pass<br>

loop()<br><br>thingwithproperty.prop NEVER creates an error.<br>(.prop is t=
he new .property)<br></div>

--089e0118329a72723504dddb028c--