jrudolph / better-future-exceptions Goto Github PK

After a glance through what I tried to achieve I think this needs much more work to be useful and elegant. The repo contains not more than a demo of one aspect of how error reporting could look like.

Thinking about it, the meaning of a "stacktrace" or a "callstack" is not so obvious with Futures. You can build arbitrarily complex data flow graphs using the Future combinators that will be executed in an asynchronous fashion. This means that you don't have the one callstack but in fact you usually have at least two entwined stages that may produce several callstacks due to asynchronicity and runtime creation of the data flow structure:

1. the creation of the data flow structure that encompasses calling Future.apply and all the other combinators, where each combinator call is called from a different callstack
2. the actual flow of data that starts from completing a Promise in the first place, which then may go through various combinator applications, to be eventually consumed somewhere

flatMap may actually do both stages in one execution thread complicating things further.

Even under the assumption that one could capture all those stacktraces at the various Future methods, you still need to think about how to present this huge amount of data (huge in relation to a simple stacktrace) to the user in a meaningful way.

On the more technical side, my suspicion is that the full-blown solution would slow Future creation/execution down significantly, so you usually wouldn't want to have the full dynamic error-reporting/stacktrace collection switched on all the time. One solution could be to write an aspect-based library that would add tracing / better error reporting facilities just for debugging purposes, so that you would just have to change configuration, instead, of having to change actual code. The obvious downside would be that you wouldn't run this in production.

For production code a more static approach like the one demoed in the current version could work where only the static user entry-points into the Future DSL are captured (instead of actual dynamic stacktraces of the calls). You would then still be able to retain the dynamic structure of the data flow itself which led to an error.

Every solution found here would also have a possible application for (reactive) streams as well.