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

Lie Ryan

3/9/2008 3:51:00 AM

I'm asking about people in c.l.py's opinion about a _probably_ very
Pythonic way of doing something if such features is implemented. It is
to be known that I'm not a Python expert and actually relatively new
to Python programming, so probably I'm just not thinking pythonic
enough yet or this feature might already exist somewhere in a
different name.
Anyway, I'm just asking for opinions, tell me problems I haven't
foreseen, or whether such things would be hard to implement, or
whether you think the idea is great or plain bad (and why).

Soft Exception
What is "Soft Exception"?
Soft Exception is an exception that if is unhandled, pass silently as
if nothing happened. For example, if a variable turns into NoneType,
it'll raise Soft Exception that it have become NoneException,
programmers that wants to handle it can handle it with a try...except
block while programmers that doesn't care about it (or know it won't
be a problem to his code) can just leave the code as it is.

Soft Exception differs from Hard Exceptions (the regular Exception) in
a way that Hard Exception must be handled at all cost or the program
will be terminated while Soft Exception allow programmers not to
handle it if they don't want to.

Soft Exception is similar to an event-based system, although Soft
Exception can only be handled by codes above it while Event-based
system can be handled by anyone aware of the handle pool. The Soft
Exception can also be thought as a Warning to the codes above it that
it has done something that the codes above might want to know.

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.

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.

Syntax change is probably unneeded and a Soft Exception class may be
created by inheriting from BaseSoftException class.

Problems:
- If the raising statement is a complex statement (like function call)
instead of just a simple statement (like assignment from an
expression) the exception might catch a similar soft exceptions from
deep _inside_ the function call and handle it as if it happened in the
code it's protecting. This problem can be solved by raising Soft
Exception only once except if explicitly reraised (perhaps through
except SoftException: raise).
This can be done by modifying a flag that is turned off (Falsed) if
the Soft Exception is raised and turned on again (Trued) if the Soft
Exception is reraised. Normal Exceptions (Hard Exceptions) would have
this flag turned off (Falsed) if it is handled and turned on (Trued)
again if it is reraised.

- To be half useful, soft exceptions have to be raised everywhere here
and there, not just here and here only. This might require a massive
change in current codes, or at least in Python's official libraries.

- Irresponsible programmers. Sometimes lazy programmers might decides
to be lazy and make all exceptions soft so he doesn't have to handle
it.

Ideology Base:
- EAAP: Easier to apologize than to ask permission.

Others:
- Sometimes it might be useful to convert a Soft Exception into Hard
Exception or vice versa.

30 Answers

Kay Schluehr

3/9/2008 5:06:00 AM

On 9 Mrz., 04:51, Lie <Lie.1...@gmail.com> wrote:

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

This will not be easy in particular in the presence of inheritance and
dynamism. There is no way to statically decide whether an exception
BException has the type AException and will be caught by the except
clause in

try:
BLOCK
except AException, e:
print "SoftException %s caught"%e

A feasible solution was to invert the try...except statement and
creating a continuation.

catch AException, a:
print "SoftException A: %s"%a
catch BException , b:
print "SoftException B: %s"%b
....
in:
BLOCK

Here each SoftException is raised initially when a catch clause is
entered and a continuation is created that returns to the catch block
of the raised SoftException if required. When a SoftException is
raised within BLOCK a lookup will be made and if a corresponding
SoftException was found that was raised by a catch-clause the current
control flow will be suspended and the continuation is called.

Steven D'Aprano

3/9/2008 5:30:00 AM

On Sat, 08 Mar 2008 19:51:24 -0800, Lie wrote:

> Soft Exception
> What is "Soft Exception"?
> Soft Exception is an exception that if is unhandled, pass silently as if
> nothing happened. For example, if a variable turns into NoneType, it'll
> raise Soft Exception that it have become NoneException, programmers that
> wants to handle it can handle it with a try...except block while
> programmers that doesn't care about it (or know it won't be a problem to
> his code) can just leave the code as it is.
>
> Soft Exception differs from Hard Exceptions (the regular Exception) in a
> way that Hard Exception must be handled at all cost or the program will
> be terminated while Soft Exception allow programmers not to handle it if
> they don't want to.

I don't think that there are very many cases where exceptions can be
ignored safely. There are two main reasons for using exceptions:

(1) Signaling an exceptional event.

(2) An error occurred.

I can't think of many cases where you would wish to ignore either, and
just continue processing. The only examples I can think of are in loops,
where you are doing the same thing over and over again with just a little
change, and you wish to skip any problematic data, e.g.:

def plot_graph(func, domain):
for x in domain:
plot(x, func(x))

If an error occurs in plot() for one particular x value, you would want
to ignore it and go on to the next point. But that's easy enough to do
with a regular try...except block.

Simply put, you're suggesting the following two alternatives:

Hard Exceptions: terminate the program unless explicitly silenced
Soft Exceptions: pass silently unless explicitly caught

In this case, I agree with the Zen of Python ("import this"):

Errors should never pass silently.
Unless explicitly silenced.

The cost of explicitly silencing exceptions is tiny, the risk of misuse
of Soft Exceptions is very high, and the benefit of them is negligible.

--
Steven

Kay Schluehr

3/9/2008 6:25:00 AM

On 9 Mrz., 06:30, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:

> Hard Exceptions: terminate the program unless explicitly silenced
> Soft Exceptions: pass silently unless explicitly caught
>
> In this case, I agree with the Zen of Python ("import this"):
>
> Errors should never pass silently.
> Unless explicitly silenced.

Exceptions in Python don't necessarily signal errors. Just think about
StopIteration.

Note also that the common practice of letting *possible* errors passed
silently is to return None instead of raising an exception. Moreove
people create boilerplate like this

try:
k = lst.index(elem)
...
except IndexError:
pass

instead of

with lst.index(elem) as k:
...

It would be interesting to think about SoftException semantics for
such clauses: lst.index would neither raises a HardException nor does
it return None but leads to skipping the with-block.

Is it really so exotic that it requires the demand for more use
cases?

Steven D'Aprano

3/9/2008 8:05:00 AM

On Sat, 08 Mar 2008 22:24:36 -0800, Kay Schluehr wrote:

> On 9 Mrz., 06:30, Steven D'Aprano <st...@REMOVE-THIS-
> cybersource.com.au> wrote:
>
>> Hard Exceptions: terminate the program unless explicitly silenced Soft
>> Exceptions: pass silently unless explicitly caught
>>
>> In this case, I agree with the Zen of Python ("import this"):
>>
>> Errors should never pass silently.
>> Unless explicitly silenced.
>
> Exceptions in Python don't necessarily signal errors. Just think about
> StopIteration.

I know that. That's why I said that exceptions were used for signaling
exceptional events.

> Note also that the common practice of letting *possible* errors passed
> silently is to return None instead of raising an exception.

"Common"? Who does that?

I know re.search() etc. return None in the event the regex doesn't match.
That's not an error.

> Moreove people create boilerplate like this
>
> try:
> k = lst.index(elem)
> ...
> except IndexError:
> pass
>
> instead of
>
> with lst.index(elem) as k:
> ...

Possibly because the with keyword is quite new and many people don't know
it, and much code was written before it even existed, or they have to
support Python 2.4 or older.

> It would be interesting to think about SoftException semantics for such
> clauses: lst.index would neither raises a HardException nor does it
> return None but leads to skipping the with-block.
>
> Is it really so exotic that it requires the demand for more use cases?

Are the existing solutions really so incomplete that we need yet another
solution?

What problem are you trying to solve with SoftExceptions?

How would changing lst.index() to raise a soft exception help here?

pos = lst.index('foo')
lst[pos] = 'bar'

What is that code going to do if 'foo' isn't found in lst and it raises a
silent, unhandled SoftException? Do you expect Python to be context
sensitive, and raise HardExceptions in some places and SoftExceptions in
others? Who controls that?

--
Steven

Lie Ryan

3/9/2008 8:31:00 AM

On Mar 9, 12:05 pm, Kay Schluehr <kay.schlu...@gmx.net> wrote:
> On 9 Mrz., 04:51, Lie <Lie.1...@gmail.com> wrote:
>
> > 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.
>
> This will not be easy in particular in the presence of inheritance and
> dynamism. There is no way to statically decide whether an exception
> BException has the type AException and will be caught by the except
> clause in
>
> try:
> BLOCK
> except AException, e:
> print "SoftException %s caught"%e

> A feasible solution was to invert the try...except statement and
> creating a continuation.
>
> catch AException, a:
> print "SoftException A: %s"%a
> catch BException , b:
> print "SoftException B: %s"%b
> ...
> in:
> BLOCK
>
> Here each SoftException is raised initially when a catch clause is
> entered and a continuation is created that returns to the catch block
> of the raised SoftException if required. When a SoftException is
> raised within BLOCK a lookup will be made and if a corresponding
> SoftException was found that was raised by a catch-clause the current
> control flow will be suspended and the continuation is called.

I'd rather want to avoid any syntax changes, as I wished that Soft
Exception can be added to the language silently[1] so that new
programmers doesn't _need_ to know about it (although knowing it could
change the way they write codes to be more structured and simple).

[1] Definition of silently: Codes that aren't aware of this
functionality shouldn't break. Adding new syntax usually means adding
keywords, making possible break in current program.

On Mar 9, 12:30 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
> On Sat, 08 Mar 2008 19:51:24 -0800, Lie wrote:
> > Soft Exception
> > What is "Soft Exception"?
> > Soft Exception is an exception that if is unhandled, pass silently as if
> > nothing happened. For example, if a variable turns into NoneType, it'll
> > raise Soft Exception that it have become NoneException, programmers that
> > wants to handle it can handle it with a try...except block while
> > programmers that doesn't care about it (or know it won't be a problem to
> > his code) can just leave the code as it is.
>
> > Soft Exception differs from Hard Exceptions (the regular Exception) in a
> > way that Hard Exception must be handled at all cost or the program will
> > be terminated while Soft Exception allow programmers not to handle it if
> > they don't want to.
>
> I don't think that there are very many cases where exceptions can be
> ignored safely. There are two main reasons for using exceptions:
>
> (1) Signaling an exceptional event.

In that case, programmers might decide whether to raise Soft or Hard
Exception. Hard Exception is much preferred.

> (2) An error occurred.

Which must always be handled with Hard Exception.

Adding another thing
(3) Informing codes above it about what's currently happening inside,
the thing is just a mundane report that might be useful to codes above

Which might be a useful place to use SoftExceptions

> I can't think of many cases where you would wish to ignore either, and
> just continue processing. The only examples I can think of are in loops,
> where you are doing the same thing over and over again with just a little
> change, and you wish to skip any problematic data, e.g.:
>
> def plot_graph(func, domain):
> for x in domain:
> plot(x, func(x))
>
> If an error occurs in plot() for one particular x value, you would want
> to ignore it and go on to the next point. But that's easy enough to do
> with a regular try...except block.

No, you're misunderstanding the purpose of Soft Exception, it's not
for silencing errors and not so much for exceptional cases. It's for
the more mundane tasks such as:

from __future__ import division

class SomeNumeric(object):
def __div__(a, b):
if b == 0: raise ZeroDivisionError ## Hard Exception, don't
ignore me!
if a == 0: raise ZeroNumerator ## Soft Exception
f = a / b
i = a // b
if f == float(i):
raise IntegerDivision ## Soft Exception
return a // b
else:
raise FloatDivision ## Soft Exception
return a / b

Most people can ignore the ZeroNumerator, IntegerDivision, and
FloatDivision exceptions (warnings) because they're excessive and
unnecessary, but some people might want to catch them and do something
else (especially ZeroNumerator). Practicle example, far below.

The example is actually quite bad at demonstrating the purpose of Soft
Exception as it is very simple while Soft Exception is generally more
useful in complex operations. But I want to avoid giving complex
examples since it'll be more difficult to explain the complex examples
instead of the simple examples.

> Simply put, you're suggesting the following two alternatives:
>
> Hard Exceptions: terminate the program unless explicitly silenced
> Soft Exceptions: pass silently unless explicitly caught
>
> In this case, I agree with the Zen of Python ("import this"):
>
> Errors should never pass silently.
> Unless explicitly silenced.

That's what sloppy programmers do, silently pass errors. OTOH, Soft
exceptions are not used for errors (perhaps the wording can be better
phrased: must not be used for errors), they're used for events that
some might have interest in, but some would consider it as normal.
That's why I mentioned to think of it as a Warning. Operations that
raise Soft Exceptions should be able to run normally even when the
exception isn't handled (although it might generate garbage out that
can be handled at later time).

> The cost of explicitly silencing exceptions is tiny, the risk of misuse
> of Soft Exceptions is very high, and the benefit of them is negligible.

Perhaps relabeling it as Warning, and renaming raise SoftException as
give Warning might make it more acceptable?
And I agree that the probability for misuse is quite high, but the
benefits is also quite high, it's just that you can't see it since
you're not used to using such exceptions. The benefit of
SoftExceptions lies mostly on the regular programmings tasks, not the
exceptional programming tasks

Practical Example:
This example takes _case ideas_ from this simple gravity simulator
http://www.pygame.org/pr... BUT _no line of code is taken from
it_. I only give this link so you can easily know what the case is
about without lengthy explanation.

A particle machine.
The particle machine calculates gravity created by the particles in a
field. Additionaly, it clumps together two particles that happens to
be near enough (less than the sum of their radiuses).

The force two particle is expressing to each other is calculated with:
def calculateforce(P1, P2):
return (P1.mass - P2.mass) / distance(P1, P2)

and this is done to every particle in the field against the current
particle.

And the distance is calculated by:
def distance(P1, P2)
return (P1.X - P2.X) ** 2 - (P1.Y - P2.Y) ** 2

The problem happens when the distance is small enough and we want to
clump them together.

A possible solution to this problem might be to check whether distance
is less than P1.radius + P2.radius in the calculateforce.
But, this obfuscate the code since we have to separate distance
calculation from the main formula (see !s), and this also insist that
clumping be done on force calculation level (see @s), shortly this
piece of code is plain bad:
def distance(P1, P2):
return (P1.X - P2.X) ** 2 - (P1.Y - P2.Y) ** 2

def calculateforce(P1, P2):
## Separating this dist calculation into its own line is
## necessary if we want to check the value of dist
## Personally I think that's a bit obfuscated.
## Well known formulas should be kept to one line if possible
! dist = distance(P1, P2)

if dist <= P1.radius + P2.radius:
## Calling clump() here is bad, because
## there are occasions where we only want to
## calculate force but doesn't want to
## clump it
@ clump(P1, P2)
else:
! return (P1.mass - P2.mass) / dist

## Codes calling calculateforce()
# Note: this code is located inside a loop

F = calculateforce(P1, P2)
# Do something else, acceleration calculation, movement
calculations, etc

A better refactoring would be like this, but this requires calculating
distance twice (see !s):
def distance(P1, P2):
return (P1.X - P2.X) ** 2 - (P1.Y - P2.Y) ** 2

def calculateforce(P1, P2):
## Here distance is calculated once
! return (P1.mass - P2.mass) / distance(P1, P2)

## Codes calling calculateforce()
# Note: this code is located inside a loop

## Here distance is calculated again
! if distance(P1, P2) <= P1.radius + P2.radius:
clump(P1, P2)
break
F = calculateforce(P1, P2)
# Do something else, acceleration calculation, movement
calculations, etc

A much better solution would be to use SoftException
def distance(P1, P2):
D = (P1.X - P2.X) ** 2 - (P1.Y - P2.Y) ** 2
if D <= P1.radius + P2.radius: raise Collision
return D

def calculateforce(P1, P2):
try:
F = (P1.mass - P2.mass) / distance(P1, P2)
except Collision:
raise

## Codes calling calculateforce()
# Note: this code is located inside a loop
try:
F = calculateforce(P1, P2)
except Collision:
clump(P1, P2)
break # Calculate the next particle pair
else:
# Do something else, acceleration calculation,
# speed calculation, movement calculations, etc

This results in a cleaner code. And it also allow _other part of
codes_ that uses calculate distance and force to easily ignore or
handle the Collision Exception. If this code had used Hard Exception,
other codes would have to explicitly silence the exception or the
program terminates. That would be too much since Collision is
technically not an Error, but just a normal events that you might be
interested to know. Soft Exception allows events of interest to be
noticed or be ignored depending on the requirement.

It's like a notice board: In the notice board, there are notices about
the Maths Test next week, which you must not ignore (Hard Exception),
but there are also notices about Part-time Job Advertisement, if
you're interested about it you can look at it further, else you could
just ignore it and do nothing (Soft Exception)

Kay Schluehr

3/9/2008 9:31:00 AM

On 9 Mrz., 09:30, Lie <Lie.1...@gmail.com> wrote:
> On Mar 9, 12:05 pm, Kay Schluehr <kay.schlu...@gmx.net> wrote:
>
> > On 9 Mrz., 04:51, Lie <Lie.1...@gmail.com> wrote:
>
> > > 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.
>
> > This will not be easy in particular in the presence of inheritance and
> > dynamism. There is no way to statically decide whether an exception
> > BException has the type AException and will be caught by the except
> > clause in
>
> > try:
> > BLOCK
> > except AException, e:
> > print "SoftException %s caught"%e
> > A feasible solution was to invert the try...except statement and
> > creating a continuation.
>
> > catch AException, a:
> > print "SoftException A: %s"%a
> > catch BException , b:
> > print "SoftException B: %s"%b
> > ...
> > in:
> > BLOCK
>
> > Here each SoftException is raised initially when a catch clause is
> > entered and a continuation is created that returns to the catch block
> > of the raised SoftException if required. When a SoftException is
> > raised within BLOCK a lookup will be made and if a corresponding
> > SoftException was found that was raised by a catch-clause the current
> > control flow will be suspended and the continuation is called.
>
> I'd rather want to avoid any syntax changes, as I wished that Soft
> Exception can be added to the language silently[1] so that new
> programmers doesn't _need_ to know about it (although knowing it could
> change the way they write codes to be more structured and simple).

I just tried to save your proposal from being unimplementable. Maybe
you can comment on it?

I know of course that syntax is Pythons holy cow but I'm not Guidos
mouthpiece and have a different perspective on some aspects of the
system for obvious reasons [1]. I appreciate when people in the Python
community talk about what is useful for them and not what the
imaginary Pythonista superego thinks about them and how it will be
standardized in the end - if anyhow.

I'd like to know if SoftExceptions would make programs more reliable
in the end because people won't use them sparingly but for all kinds
of events that are somewhat "irregular" ( i.e. warnings ) not just for
obvious errors. It's an interesting idea to have an advanced warning
system that is more responsive than just this kind of logging which is
currently implemented. And I'd surely discriminate them from the
current exception handling at least in the design phase. Later
language changes could still be "dissolved".

[1] http://www.fiber-space.de/EasyExtend/d...

Mel

3/9/2008 11:22:00 AM

Lie wrote:
[ ... ]
> Soft Exception
> What is "Soft Exception"?
> Soft Exception is an exception that if is unhandled, pass silently as
> if nothing happened. For example, if a variable turns into NoneType,
> it'll raise Soft Exception that it have become NoneException,
> programmers that wants to handle it can handle it with a try...except
> block while programmers that doesn't care about it (or know it won't
> be a problem to his code) can just leave the code as it is.
>
> Soft Exception differs from Hard Exceptions (the regular Exception) in
> a way that Hard Exception must be handled at all cost or the program
> will be terminated while Soft Exception allow programmers not to
> handle it if they don't want to.
[ ... ]
> Ideology Base:
> - EAAP: Easier to apologize than to ask permission.

Sort of like a COME FROM statement. Drastic effects on program
execution: a `raise SoftException` in the middle of a loop would break
the loop if a catcher existed, or leave the loop running if not. It
would really need the ability to resume after catching an exception.
You can't really talk about 'apologize' around something that's so
irreparable.

I'd try for this effect by creating a class of objects with
well-defined callbacks.

Mel.

Bryan Olson

3/9/2008 11:57:00 AM

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?

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.

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.

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

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.

--
--Bryan

Lie Ryan

3/9/2008 12:28:00 PM

On Mar 9, 6:57 pm, Bryan Olson <fakeaddr...@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.

Lie Ryan

3/9/2008 12:50:00 PM

On Mar 9, 4:31 pm, Kay Schluehr <kay.schlu...@gmx.net> wrote:
> On 9 Mrz., 09:30, Lie <Lie.1...@gmail.com> wrote:
> > On Mar 9, 12:05 pm, Kay Schluehr <kay.schlu...@gmx.net> wrote:
>
> > > On 9 Mrz., 04:51, Lie <Lie.1...@gmail.com> wrote:
>
> > > > 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.
>
> > > This will not be easy in particular in the presence of inheritance and
> > > dynamism. There is no way to statically decide whether an exception
> > > BException has the type AException and will be caught by the except
> > > clause in
>
> > > try:
> > > BLOCK
> > > except AException, e:
> > > print "SoftException %s caught"%e
> > > A feasible solution was to invert the try...except statement and
> > > creating a continuation.
>
> > > catch AException, a:
> > > print "SoftException A: %s"%a
> > > catch BException , b:
> > > print "SoftException B: %s"%b
> > > ...
> > > in:
> > > BLOCK
>
> > > Here each SoftException is raised initially when a catch clause is
> > > entered and a continuation is created that returns to the catch block
> > > of the raised SoftException if required. When a SoftException is
> > > raised within BLOCK a lookup will be made and if a corresponding
> > > SoftException was found that was raised by a catch-clause the current
> > > control flow will be suspended and the continuation is called.
>
> > I'd rather want to avoid any syntax changes, as I wished that Soft
> > Exception can be added to the language silently[1] so that new
> > programmers doesn't _need_ to know about it (although knowing it could
> > change the way they write codes to be more structured and simple).
>
> I just tried to save your proposal from being unimplementable. Maybe
> you can comment on it?

Perhaps I'm not the appropriate person to talk about whether unchanged
syntax is feasible for such implementation since I basically have no
idea about how Python's internals works. It's only that I think if
current syntax could be used, we could just use it (except if there is
a strong reason why it shouldn't be done).

> I know of course that syntax is Pythons holy cow but I'm not Guidos
> mouthpiece and have a different perspective on some aspects of the
> system for obvious reasons [1].

I agree, everybody have different perspective. But that differences is
what makes languages evolves as it'd be continuously searching for the
most optimal perspective.

comp.lang.python

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

Lie Ryan

Kay Schluehr

Steven D'Aprano

Kay Schluehr

Steven D'Aprano

Lie Ryan

Kay Schluehr

Mel

Bryan Olson

Lie Ryan

Lie Ryan

x Login to ForumsZone