Investigate making it harder to leave a flow dangling

[theangrydev]

Currently it is all too easy to have an exception swallowed by the framework and to not handle it. Issue #8 will help with this a little in void cases, but I have another idea.

There could be a checked FlowInProgress exception that is declared on all the methods apart from the ones that end a flow like join. This would give a compile time error if the exception is not caught or declared, which could prompt someone to end the flow. Ideally the compiler would also prevent catching the exception, not sure if that is possible.

This is all just a hack to try to make it hard to make the mistake of having swallowed exceptions that do not end up in the application logs.

[theangrydev]

The above idea doesn't work because the exception will still need to be declared even if it is chained. The only other idea I have is to have a ThreadLocal that stores a flow when it is constructed and clears it when any of the "end of flow" methods is called. The ThreadLocal could be inspected using a static BusinessFlow.checkFlowWasEnded method that throws an exception if the old one has not been cleared. This method could be called in some generic place such as the end of a HTTP request handler inside a web server (so if you forget to end a flow during development, hopefully you would notice because the generic handler would blow up).

[theangrydev]

The above idea is complicated by e.g. nested flows, which is a common use case. Would need something like a Set of flows in progress that is modified at the appropriate times (e.g. a join ending a flow, or a then ending an outer flow in favour of an inner flow). The implementation would be messy and tedious to test, but it is possible.

Alternatively, it could just be accepted as a known limitation and users need to just be careful to not leave flows dangling.

[theangrydev]

Oh and it goes without saying that the ThreadLocal approach makes the assumption that flows begin and end in the same thread.