This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Add new check `bugprone-unhandled-exception-at-sto`
Needs ReviewPublic

Authored by Sockke on Jun 27 2022, 11:14 PM.

Details

Summary

Calls to stoi and stod families of functions may throw exceptions so they need to be surrounded by try/catch.

Diff Detail

Event Timeline

Sockke created this revision.Jun 27 2022, 11:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 27 2022, 11:14 PM
Sockke requested review of this revision.Jun 27 2022, 11:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 27 2022, 11:14 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

I think will be good idea to make check more generic and allow user-defined list of unsafe functions.

clang-tools-extra/docs/ReleaseNotes.rst
135

Please keep entries in alphabetical order in section.

138

Please follow 80 characters limit.

clang-tools-extra/docs/clang-tidy/checks/bugprone/unhandled-exception-at-sto.rst
6

Ditto.

15

Ditto.

This whole check seems weird to me. I mean, almost every use of a standard container could throw std::bad_alloc but we don't insist on a local catch for bad_alloc at every possible throwing call site.

Why would we assume that every call site of stoi or stod must have an exception handler immediately around it? It's perfectly acceptable for an application to handle this at an outer scope that can't be detected by clang-tidy.

Sockke added a comment.Jul 8 2022, 4:09 AM

I think will be good idea to make check more generic and allow user-defined list of unsafe functions.

I understand that user-defined is implemented through the config, but some types of information of user customization cannot be well described here. Maybe use function name and argument counts only to match unsafe functions?

Sockke added a comment.Jul 8 2022, 4:13 AM

This whole check seems weird to me. I mean, almost every use of a standard container could throw std::bad_alloc but we don't insist on a local catch for bad_alloc at every possible throwing call site.

Why would we assume that every call site of stoi or stod must have an exception handler immediately around it? It's perfectly acceptable for an application to handle this at an outer scope that can't be detected by clang-tidy.

Makes sense, I implemented this check here because some projects in ByteDance used stoi with missing exception handlers caused an online crash, I think this is a relatively common problem. Perhaps only report diagnostics for stoi calls in nothrow functions?

Friendly ping.

Friendly ping.

This whole check seems weird to me. I mean, almost every use of a standard container could throw std::bad_alloc but we don't insist on a local catch for bad_alloc at every possible throwing call site.

Why would we assume that every call site of stoi or stod must have an exception handler immediately around it? It's perfectly acceptable for an application to handle this at an outer scope that can't be detected by clang-tidy.

Makes sense, I implemented this check here because some projects in ByteDance used stoi with missing exception handlers caused an online crash, I think this is a relatively common problem. Perhaps only report diagnostics for stoi calls in nothrow functions?

I don't have anything more to add; I mean, you answered my question with another question. I still don't see that this check is making things better. Have you run it on large code bases to see what kind of nuisance it creates?