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.