[c++] raise a clear error for unknown metric types

[FranciscoRMendes]

Summary

When a user passes an unknown metric name to lgb.train() or lgb.cv(), LightGBM previously silently proceeded with no evaluation metrics. In the R package this caused a confusing crash inside the callback machinery (subscript out of bound) rather than a clear
error pointing to the bad metric name.

The fix is in Metric::CreateMetric() (src/metric/metric.cpp:L139 (

LightGBM/src/metric/metric.cpp

Line 139 in 4472f39

return nullptr;

)): it now calls Log::Fatal for any unrecognised metric name, before returning.
The only exception is the "custom" sentinel that ParseMetricAlias produces for "none" / "na" / "null" / "custom" — those are intentional no-ops and still return nullptr.

Tests

• R: two new test_that blocks in test_basic.R for lgb.train() and lgb.cv()
• Python: new tests in test_engine.py covering an unknown metric name, the sentinel string values ("none", ["none", "null"], ["None"], ["NULL"]), and Python None

Contributes to #3481

[jameslamb]

Thanks for the help on this long-standing usability issue!

I'm supportive of raising an error in this situation, as @guolinke was back in 2020: #3481 (comment)

The R and Python tests look pretty good, thanks very much for following the existing patterns in the code base and keeping those tests focused and lightweight.

---

Metric::CreateMetric() returned nullptr for any unrecognised metric name.

Please use commit-anchored links (GitHub docs) when referring to code specifics like this. In this case:

LightGBM/src/metric/metric.cpp

Line 139 in 4472f39

return nullptr;

It helps reviewers to quickly navigate to the code you're referring to, and to see a preview of it rendered in the GitHub UI to avoid needing to click at all.

---

In #3481 (comment), @guolinke wrote:

The same strategy could be adapted to objective functions

Did you look into that at all? If not, would you be interested in doing that in a follow-up PR?

If so, the PR description should be changed from "Closes" to "Contributes to"... that issue is tracking doing this for both metrics and objective functions.

---

Test plan

The PR description is clear and thorough, thanks for that. I've seen this exact structure many times recently (GitHub search), and know it's the type of thing that's generated by LLMs.

Use the tools you want for coding, but when you contribute here, please:

• write explanatory text (comments, PR description, issue description) yourself... I'm happy to talk to you, I do not want to talk to an LLM through you
• be ready to explain your thought process and the meaning of the submitted code yourself ("I'm not sure, this is what the LLM said" will not be acceptable)

[jameslamb]

I'll take a closer look at these PRs tonight, but just a quick note... you don't need to rebase and force-push in this repo. We squash all commits to 1 on merge.

In fact, we'd generally prefer you didn't force-push once PR review has started. That makes it easier for reviewers to see what you changed in response to the conversation.

Work however you're comfortable working, just letting you know you don't need to worry too much about the individual commit history within a PR because we squash.