@moellney said:
Anyway, my intention for this discussion was not to start a discussion about pro/contra of exceptions, though.
Yup, sorry. One of the downsides of exceptions is it's almost impossible to talk about them without talking about whether they're worth it.
My question was more, if there is an established design concept
Well, as the link you originally posted says - exceptions thrown across connections are undefined behavior. This in practice means that anything that can be used in a Qt connection should not throw exceptions. This means any method of a QObject derived class, any free standing function, lambda or functor you intend to use in a connection. So yes, you should mark all of that noexcept and generally the more localized your exception handling is the better/safer. As for threading - exception handling is only supported by QtConcurrent and QException derived exception types. Anything else is unspecified, so basically a no-no.
If you build models/backend around exceptions don't just keep them local and make sure you catch them before crossing into the Qt land.
I'm still looking into details about the STL
Yeah, this is one of the reasons I wish noexcept had different defaults :( Implementations like this make things slow by default, which is very sad for C++.