Fix TypeError in _.max/_.min on nullish collection with numeric iteratee#3018
Fix TypeError in _.max/_.min on nullish collection with numeric iteratee#3018dkempner wants to merge 1 commit into
Conversation
The fast-path guard accessed obj[0] before checking obj != null, so _.max(null, 0) threw a TypeError instead of returning -Infinity like _.max(null) and _.max(null, _.identity) do. Reorder the conditions so the null check comes first. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Thanks for disclosing that you used a genAI tool, I highly appreciate that. The proposed change looks sane and correct to me, in fact it is currently a mystery to me why the conditions are in the wrong order. I will be diving in the commit history to figure that out. In the meanwhile, could you tell me a bit more about how you ran into this issue? What does the line in your own code look like, where this exception was being triggered by |
No production code to share. I was just using underscore as a way to test Fable's code spelunking capability. Feel free to close if you think this isn't worth the merge. |
|
I will not close it (at least not yet), but I will take more time to review this critically. |
_.max(null)and_.max(null, _.identity)both return-Infinity, but_.max(null, 0)throws:The fast-path guard in
max/minreadstypeof obj[0] != 'object'before theobj != nullcheck, so a nullish collection combined with a numeric iteratee dereferencesnullbefore the null check can short-circuit. This PR reorders the conditions so the null check comes first;_.max(null, 0)and_.min(null, 0)now fall through to the iteratee branch and return-Infinity/Infinity, consistent with every other nullish-collection case.No behavior change for non-nullish collections — the numeric fast path and the falsy-iteratee lookup cases (
_.max([[1], [2, 3]], 0)) are unaffected, and regression tests for both functions are included. Full test suite passes (208/208).🤖 Generated with Claude Code