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

[Diez B. Roggisch]

metawilm at gmail.com schrieb:
> On Mar 9, 2:21 pm, "Diez B. Roggisch" <de... at nospam.web.de> wrote:
>> Is this soft-exception implemented anywhere, so that one can see what
>> experiences and best practices have evolved around using it?
> 
> Lie's idea is to separate exceptions in two groups, those that must be
> handled and those that don't. A better way is to have two different
> ways to raise exceptions: one exceptional situation can be "Hard" in
> some situations and "Soft" in others, and it is up to the way of
> raising to make the choice, while the exception stays the same.
> 
> Common Lisp has two ways of raising: functions "error" and "signal".
> Python's "raise" is like CL's "error": you end up in the debugger if
> the exception is not handled. Exceptions that are raised by CL's
> "signal" don't have to be caught: if there is no matching "except"
> clause the raise statement becomes a "pass".
> 
> Or as Wikipedia states nicely: "Conditions are a generalization of
> exceptions. When a condition arises, an appropriate condition handler
> is searched for and selected, in stack order, to handle the condition.
> Conditions which do not represent errors may safely go unhandled
> entirely; their only purpose may be to propagate hints or warnings
> toward the user."

How would that differ from something like this:


with add_soft_handler(SoftException):
    invoke_something()

... # deep down in code

raise_soft(SoftException())


The implementation of add_soft_handler and raise_soft is trivial - a bit 
of thread-local storage and a stack.

I don't say that such mechanism isn't handy occasionally - I just don't 
see the need for specialized syntactical and/or interpreter-support.

Diez