Closed aengelberg closed 6 years ago
Deferreds are functions because that's how Clojure's promises work, and deferreds are supposed to act as drop-in replacements. I'm not sure how to avoid this sort of mistake without precluding valid use cases, but I'm happy to hear any suggestions you might have.
Hmm. I had thought that one solution would be for d/chain
to just throw an exception if the chained "functions" were specifically deferreds. But the more I think about it, one might legitimately (but not particularly wisely) use the sugared delivery mechanism as a callback in d/chain
:
(let [d (d/deferred)]
(d/chain
(do-a-thing)
;; when my thing is done, deliver the result into `d`
d)
d)
So in that case I'm also not sure of a good way to eliminate my above mistake.
Yeah, in those cases I'd just put a #(success! d %)
in the chain, but I'm sure someone's done what you describe and I can't willfully break it. I'm going to close the issue, but I do apologize for the time you spent tracking this down.
I accidentally forgot to wrap a chain callback in
fn
so I ended up basically chaining a deferred to a deferred. Here's the scenario:But rather than a type error I get back mysterious "successful" results:
I see now that deferreds appear to intentionally implement
IFn
as a syntactic sugar for delivering things into it, so that explains the errors. But it would be nice ifd/chain
had some guards to protect against this class of mistake.