A Twisted Design Decision

[koranthala]

Twisted, being twisted in its behavior is causing quite a lot of
confusion in design decisions.

I will put forward a comparison of reactor and non-reactor patterns.
The code is not exact - whatever is shown is the gist of it.

For example, a message handler - in a usual scenario:
class messageHandler:
def run():
msg = self.get_next_msg()
if not msg.send():
self.handle_failure()

To handle parallel execution, we will have to use threads, but the
code flow is similar.

How do we do the same in a reactor pattern (Twisted)?
msg.send will cause a deferred to be raised - the failure, if it
happens will happen much later.
i.e. other than sending messageHandler object in msg.send(), I cannot
see any mechanism of running handle_failure.

In Twisted:
class messageHandler:
def run():
msg = self.get_next_msg()
msg.send(self):

class msgClass:
def send(o):
d = deferred.addCallBack(success_handler, o).addErrBack
(failure_handler, o)

def failure_handler(o):
o.handle_failure()

Basically, what I find is that a lot of functional encapsulation is
now lost by following reactor pattern. handle_failure is
messageHandlers code and makes for pretty viewing if called from
inside messageHandler itself. But, due to the twisted nature of
reactor pattern, the msg Class - who is functionally a lower class to
messageHandler invoking messageHandler's code.

Is there a way to solve this in a more beautiful way? Am I missing
something here?