2 ms·
Define "fundamentally". In the end it all comes down to NAND gates... ;-) But yes, it is very, very different. With an exception, which does achieve a simil
by mpweiher 3y ago
Define "fundamentally". In the end it all comes down to NAND gates... ;-)
But yes, it is very, very different. With an exception, which does achieve a similar effect of stopping further execution right there and then, you need to throw the exception and you need to check it. With dataflow, all you have to do is nothing.
And exceptions are quite a tricky and heavyweight mechanism. What about the intermediate code? Does it need to run despite the exception? Will it just swallow the exception instead of passing it on? You can just pass the final error handler in and set it on the filter and there is no trickiness.
And of course without the exception, there is a lot of code that needs to do error handling despite not really being involved. This becomes really, really noticeable when your async code is handled using callbacks. You just get two sets of callback everywhere. Just having the code be synchronous would be better, but with dataflow the whole issue just evaporated.
- gpderetta 3y agoIn the end it boils down to continuations: your function either either takes a single return continuation that takes result|error variant or it takes two (or more) continuations: one for the happy path, and one for the error path. The former maps well to result objects, the latter is maps better to non local (checked) exceptions, but it easy to see how to transform from one to the other.
- mpweiher 3y ago> In the end it boils down to continuations No it does not. > your function Only if you deal exclusively with procedures/functions. With dataflow, that's not the case. You have two filters, and if the first filter detects an error, it just does nothing (i.e it does not pass the value to the second filter). Done. No need for exceptions or continuations, or weird return types.