> 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
--
http://mail.python.org/mailman/listinfo/python-list
