Code Health: Consider disabling warning C26440 #5995

Open
opened 2026-01-31 00:27:23 +00:00 by claunia · 0 comments
Owner

Originally created by @j4james on GitHub (Jan 16, 2020).

In one of the PRs I'm working on, I found I was getting errors from the audit mode build because it wanted me to declare certain methods as noexcept (warning C26440). But the methods in question were calling the std:array::at method, which throws an exception, so I would have thought they couldn't be noexcept.

You can see an example of this in the TerminalSettings::GetColorTableEntry method:

a60ed52064/src/cascadia/TerminalSettings/TerminalSettings.cpp (L76-L79)

It's calling std:array::at, so it clearly can throw an exception, but it's still declared as noexcept. And removing that noexcept will trigger above-mentioned error in the audit mode build.

So what is the recommended practice here? Do we just add noexcept to the method even though that's not actually true? Do we suppress the warning on a case by case basis? (Per function, or per compilation unit?) Or should we consider disabling the warning for the entire project, at least until it's more reliable?

Originally created by @j4james on GitHub (Jan 16, 2020). In one of the PRs I'm working on, I found I was getting errors from the audit mode build because it wanted me to declare certain methods as `noexcept` (warning [C26440](https://docs.microsoft.com/en-us/visualstudio/code-quality/c26440)). But the methods in question were calling the `std:array::at` method, which throws an exception, so I would have thought they couldn't be `noexcept`. You can see an example of this in the `TerminalSettings::GetColorTableEntry` method: https://github.com/microsoft/terminal/blob/a60ed520649920cc50167d58075e69302ccc5ce9/src/cascadia/TerminalSettings/TerminalSettings.cpp#L76-L79 It's calling `std:array::at`, so it clearly can throw an exception, but it's still declared as `noexcept`. And removing that `noexcept` will trigger above-mentioned error in the audit mode build. So what is the recommended practice here? Do we just add `noexcept` to the method even though that's not actually true? Do we suppress the warning on a case by case basis? (Per function, or per compilation unit?) Or should we consider disabling the warning for the entire project, at least until it's more reliable?
claunia added the Issue-TaskProduct-MetaArea-CodeHealth labels 2026-01-31 00:27:23 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#5995