3 ms·
I think the article's point is that with Future's you can still pretty easily invoke a Future-returning function and forget to return its value, ending up with
by acjohnson55 9y ago
I think the article's point is that with Future's you can still pretty easily invoke a Future-returning function and forget to return its value, ending up with what you might call an orphan continuation.
- z0r 9y agoWouldn't the unreferenced Future, once fulfilled, be garbage collected?
- _Codemonkeyism 9y agoYes
- _Codemonkeyism 9y agoIf the future has a side effect I'm not concerned with, like sending a mail, I can't see the problem?
- acjohnson55 9y agoThe problem is much like the author said -- it's easy to have errors disappear into the ether in a way that is much less likely in synchronous logic. Also, if those side-effects matter, it's easy to make faulty assumptions about time ordering. The most obvious situation to me is in the way asynchrony exists in front-end programming and how this affects testability. If you can't actually know when a process (like an animation) ends, you can't accurately test. In general, my experience has been that reification of abstract things often presents benefits in the long run. Reification of functions admits a whole host of techniques. Reification of classes facilitates metaprogramming. Reification of in-flight processes as promises helps with being able to compose and abstract over them. Nurseries seem like reficiation of an finite execution context.
- _Codemonkeyism 9y agoI'm not following, how could an error with Future[Either[A,B]] disappear compared to synchronous logic of Either[A,B]? Our code base is the same for sync and async logic and error handling. One thing that doesn't work is Anders Hejlsbergs method of letting unchecked exceptions bubble up, but exceptions haven't been a good idea for business code anyway.