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

[Diez B. Roggisch]

> The problem with callbacks is that it works only for a small amount of
> callbacks, it'd be too messy to have twenty different callbacks.
> And the ultimate problem with callbacks is that we can't determine
> from the outside whether the operation should continue or breaks at
> the point of the callback without some messy trick.
> 
> We can't always determine whether we want to do this:
> def somefunc(argA, argB, callback = DO_NOTHING):
>     if argA == argB:
>         callback()
> 
> or this:
> def somefunc(argA, argB, callback = DO_NOTHING):
>     if argA == argB:
>         callback()
>         return
> 
> perhaps we could do this:
>     if argA == argB:
>         if callback() == True: return
> 
> but that's so much extra codes written and would've been too messy to
> write.
> 
> And actually this isn't a rare cases, and in fact is very common. It's
> just that most cases that can be more cleanly written in
> SoftException, can usually be handled in different ways, using tricks
> that range from subtle to messy (like callbacks).

I fail to see how your arguments follow.

Regarding the number of callbacks: you can as well pass an object that 
has several methods to call.

And the above example can easily be accomplished with "normal" 
exceptions, like this:


def toplelevel():
     def callback(a, b):
         if a == b:
            raise InterruptException()
     try:
          work(callback)
     except InterruptException:
          pass

def work(callback=callback):
     a = 10
     b = 20
     callback(a, b)

And even more: the callback-approach can do things like this:

a, b = callback(a,b)

to change values, which makes it superior to SoftExceptions - unless I 
missed it's ability to capture context.

So far, you haven't shown a very convincing example of what 
SoftException are and how they can be useful.

Diez