What c.l.py's opinions about Soft Exception?

[Lie]

On Mar 9, 6:57 pm, Bryan Olson <fakeaddr... at nowhere.org> wrote:
> Lie wrote:
>
> [...]> Soft Exception is an exception that if is unhandled, pass silently as
> > if nothing happened.
>
> [...]
>
> > Implementation:
> > Simple implementation might be done by catching all exceptions at the
> > highest level, then filtering which exceptions would be stopped (Soft
> > Exception) and which exceptions will be reraised and terminate the
> > program (Hard Exception). This is simple and can be easily implemented
> > but is inefficient as that means all soft exceptions must bubble
> > through its way to the top to find out if it is Soft or Hard.
>
> If I'm following what you want, that "simple implementation" does
> not work.  If a function, possibly deep in a call stack, raises a
> soft exception that no caller above catches, what executes next?

The highest possible code that could catch exceptions would have
something like this:

    try:
        ## Everything is happening inside me
    except SoftException:
        pass

> Correct me if I'm misunderstanding your idea: You want raising
> an un-caught soft exception to be equivalent to a 'pass';
> execution continues as if the 'raise' never happened.
>
> Catching everything at a high level does nothing like that. The
> exception causes execution to leave the function invoking the
> raise statement, and abolishes the stack state from the point of
> the raise to the point of the catch.

The high-level mentioned here is outside our own code, it'll be inside
Python's internal. When CPython (or any implementation of Python) sees
that a particular exception is raised to a certain point, it'll check
whether it is of type SoftException, and if it is, it'll return
program state to the place where the exception is raised before. I
don't know how Python's exception system works (as I tell you I know
next to nothing about Python's internal, although I'm interested to
know), so probably if there is any defect in the implementation
schemes I mentioned, it is simply caused by my ignorance.

> As Python exceptions currently work, "catching all exceptions
> at the highest level" is either what Python already does, or
> ill-defined nonsense. When an exception is uncaught, there is
> no useful "highest level", other than the level at which the
> program simply fails. Python *must* terminate execution upon
> an unhanded exception, because the program defined no state
> from which executions could correctly continue.

That's where the difference between Soft Exceptions and Hard
Exceptions lies. Soft Exception must be continued while Hard
exceptions must terminate programs. Possibly this is impossible at the
absolutely highest level, perhaps it should be done at the level that
can guarantee

> > A more through implementation would start from the raiser inspecting
> > the execution stack and finding whether there are any try block above
> > it, if no try block exist it pass silently and if one exist it will
> > check whether it have a matching except clause. This also circumvents
> > a problem that simple implementation have, as described below.
>
> The described problems do not include the "where should execution
> resume" problem, which I think is central to the issue.

I didn't mentioned it?
I think it's obvious when I say: Execution should resume as if nothing
happened, as if there is nothing raised, that means execution resumes
at the point after the raise statement. If something was caught,
execution isn't resumed and execution continues at the level of the
handler (possibly we could also add a "resume" to explicitly resume
the statement that was caught)

> Correct me
> if I've misunderstood: A "soft" exception is one that gets raised
> only if some calling frame has arranged to catch it.

That could be a way to implement it. And btw, that's a one-line-
explanation that hits the right note (although from a different view I
initially mentioned).

> The if-exception-would-be-unhanded-then-pass logic strikes me as
> interesting. It would be a huge change to Python, so I doubt it
> will get traction here.  Still, I'd say it's worth more
> consideration and discussion.