On Mon, 26 Aug 2024 at 22:51, Thiago Macieira <thiago.macie...@intel.com> wrote: > > 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.
Right. Preconditions are as-if in the function body. Both for definition-side checks and for caller-client side checks. Otherwise a noexcept isn't a noexcept, and nobody wants that. > 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. It doesn't mean that an exception will bubble up all the way to main(). A caller can catch it. See https://open-std.org/JTC1/SC22/WG21/docs/papers/2024/p3318r0.html for some additional rumination. The state is unexpected, but recoverable - and that state doesn't mean that the program as a whole is in a completely undefined state, especially because the precondition check threw before such a state would've been entered. And it's not runtime _validation_. It's runtime recovery from logic errors. Java does this too. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
