Distributed asynchronous message driven systems are inherently complex when it comes to handling partial failures. Data flow diagrams can be used to describe and design the staged computation in distributed message driven systems by showing how messages flow between components. Data flow diagrams can drive the automatic synthesis of application executables, i.e. source code can be generated from data flow diagrams.
Data flow diagrams, however, have limitations when it comes to partial failure handling. In a data flow, a failure manifests as a fault message. The functional path of a data flow can be instrumented with junctions for fault messages. However, this approach is unfeasible for handling failures because multiple different failures can occur at any stage (partial failure) and can affect parallel data flows. Furthermore, multiple instances of a data flow can be active at the same time. For this reason, capturing which part in which instance of a data flow is affected by which kind of failure would require diagramming all combinations of data paths under faults. Such an approach is simply unfeasible in most situations.
Distributed asynchronous message driven systems are also inherently complex to debug. Traditional stack-based debuggers are not typically useful in distributed asynchronous environments since local stacks are meaningless. Similarly, setting traditional breakpoints on source code lines is also of little value in such an environment since multiple instances of the same lines of code are running concurrently with each other.