On Monday 26 August 2024 12:27:47 GMT-7 Giuseppe D'Angelo via Development wrote: > Il 26/08/24 19:56, Thiago Macieira ha scritto: > > > I'd like to request Qt code not obey that rule. In my opinion, it's a > > defect in the contract implementation rather than on Qt code. The*pre* > > condition indicates something that must be true before the method is > > called and therefore the method's own noexcept specification does not > > apply*yet*. > > As far as I've understood, that's only part of the issue. The other part > of the issue is that code calling the function may break: if you turn > the failed precondition check into an exception, the exception handling > will need to bubble it up through code which may not have set up the > correct unwinding state -- because it rightfully assumed that no > exception would escape out of a noexcept function.
How is that my problem? My code didn't throw. It was the user's action of a) turning precondition checks into runtime validations b) using exceptions for the runtime validation c) violating the precondition that caused the problem. In particular, I don't see why (b) should be used at all. A precondition violation implies that the state was unexpected at that point. How is an exception going to help recovering? That sounds like an exception that would bubble up all the way back to main() and at best perform an emergency save of state. But all of that is implementable with a termination handler too. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
