https://bugs.kde.org/show_bug.cgi?id=410751
Bug ID: 410751
Summary: [check proposal] not emitting signals in noexcept
function
Product: clazy
Version: unspecified
Platform: Other
OS: All
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: unassigned-b...@kde.org
Reporter: jeanmichael.celer...@gmail.com
CC: smart...@kde.org
Target Milestone: ---
SUMMARY
This is a proposal for a new check ; for every method, the following assertion
must hold :
- if the method emits a signal, then the method must not be marked noexcept (or
conversely, if a method is marked noexcept, it must not emit signals).
The rationale is that while your class may not throw any exceptions, maybe the
user of your class does and expects to be able to catch them at the top of the
event loop, e.g. simply to have a catch-all to show an error dialog to the
user.
But if you mark e.g. a setter for a property noexcept, it means that all the
persons who will connect to your propertyChanged signal must also ensure that
no exceptions are thrown from their side, else they get std::terminate.
The check could be relaxed if the slot of the signal is also marked noexcept.
I don't think that we should aim to make the check recursive since this
requires whole-program analysis, but just having it run on the main emitters of
signals (generally setFoo(...) functions) would already go a long way towards
preventing crashes due to over-zealous noexcept refactorings.
--
You are receiving this mail because:
You are watching all bug changes.
