[CLJ-1145] thread-last can't accept 0 or 1 forms, thread-first can't accept 0 forms Created: 12/Jan/13 Updated: 13/Jan/13 Resolved: 13/Jan/13
|Reporter:||Víctor M. Valenzuela||Assignee:||Unassigned|
At times, as the artifact of repl experimentation or a refactoring in progress, one wants to eval a threaded form with 1 or (less likely) 0 arguments.
(-> 42) ; fine
(->) ; throws "ArityException Wrong number of args (0) passed to: core$" (sic)
Apologies for the text rendering (how to cite code?).
|Comment by Andy Fingerhut [ 12/Jan/13 3:29 PM ]|
If arity 0 is a new aspect of this ticket, what would you expect the arity 0 versions to be transformed into? nil?
|Comment by Víctor M. Valenzuela [ 12/Jan/13 6:46 PM ]|
Surely a duplicate - but Jira's search couldn't find those! (used "->", "thread-last" etc as search queries).
While fairly unlikely to use / noisy to implement, the thing about feeding 0-arities to the threading macros is that they throw in exchange an unrelated exception rather than e.g. "ArityException Wrong number of args (0) passed to: core$->".
Don't know if this is simply how macros (can) work, but it called my attention.
Feel free to close my issue.
|Comment by Andy Fingerhut [ 13/Jan/13 9:25 AM ]|
I will go ahead and close this case as a duplicate. FYI, below is the behavior if the CLJ-1121 patch CLJ-1121-v002.patch and the CLJ-1083 patch CLJ-1083-attachments/better-throw-arity-messages.diff are both applied (the second one improves the error message in the 0-arity case):
|Comment by Andy Fingerhut [ 13/Jan/13 9:40 AM ]|
The issue of a poor error message with 0-arity threading macros is improved by the patch attached to ticket CLJ-1083, and adding handling of the 1-arity case is improved by the patch attached to ticket CLJ-1121.