Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #46375 > unrolled thread

Re: Fatal Python error

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Fatal Python error Joshua Landau <joshua.landau.ws@gmail.com> - 2013-05-29 14:02 +0100

#46375 — Re: Fatal Python error

[Multipart message — attachments visible in raw view] — view raw

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)

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web