[PATCH] D97196: [clang-tidy] Add new check 'bugprone-unhandled-exception-at-new'.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM!



================
Comment at: clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-exception-at-new.rst:7
+Finds calls to ``new`` that may throw ``std::bad_alloc`` exception and
+the exception handler is missing.
+
----------------
balazske wrote:
> aaron.ballman wrote:
> > This isn't quite accurate -- if the exception handler is missing or doesn't handle either `std::bad_alloc` or `std::exception`.
> I restructure the text, but do not want to mention `std::exception` because it is a base class (handling of `std::exception` means handling of `std::bad_alloc`), and then why not mention generic exception handler (`catch(...)`). I think this text is for introduction only, should not be totally precise.
The restructured text is good -- I just wanted the information *somewhere* so that users weren't surprised by the behavior.


================
Comment at: clang-tools-extra/test/clang-tidy/checkers/bugprone-unhandled-exception-at-new.cpp:20
+using badalloc3 = std::bad_alloc &;
+
+void *operator new(std::size_t, int, int);
----------------
balazske wrote:
> aaron.ballman wrote:
> > Another interesting test case would be when the user subclasses `std::bad_alloc` and throws errors of the subclass type from the allocation function which are in/correctly caught.
> In this case the check must find every (visible) subclass of `std::bad_alloc` check if there is a catch block for every case. Even then a custom allocation function may throw other classes (not derived from `std::bad_alloc`) or classes (may be inherited from `std::bad_alloc` but not visible in the TU) that are not checked. So this is still a partial solution, probably not better than the rule that a handler for `bad_alloc` (or more generic) should exist.
> So this is still a partial solution, probably not better than the rule that a handler for bad_alloc (or more generic) should exist.

Okay, that's fair -- we can always address it in follow-up if it turns out to be an issue in practice.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97196/new/

https://reviews.llvm.org/D97196