[Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Thursday 21 January 2016 22:44:02 Andre Somers wrote:
> On 21-1-2016 21:09, Milian Wolff wrote:
> > On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote:
> >> Op 21/01/2016 om 05:35 schreef Thiago Macieira:
> >>> On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:
> >>>> Thiago Macieira wrote:
> >>>>> The copy constructor is called once, then the move constructor. If
> >>>>> value_type's move constructor is not noexcept, then it may throw
> >>>>> after the
> >>>>> container resized.
> >>>> 
> >>>> Throwing an exception in a move constructor is really, really
> >>>> horrible. I can see why a copy constructor would throw (out of
> >>>> memory, failure to duplicate some other resource), but a move?
> >>> 
> >>> Indeed.
> >>> 
> >>> But the class in question may not have a move constructor. In the
> >>> absence of one, the copy constructor gets called.
> >> 
> >> I generally don't care. If I can't copy anymore due to running out of
> >> memory, I'm pretty much done anyway. No reliable way to recover from
> >> that. Might as well terminate the program.
> > 
> > Right, _you_ don't care. But as a library one cannot usually make such
> > claims. People may want to use it in conditions where they _do_ care,
> > and for good reason. It would be a shame if C++ would not be applicable
> > for such scenarios just because some people didn't care enough.
> 
> So, please, enlighten me. What would be a realistic way to recover from
> such an exception?

Take a server as an example. All it needs to do is return an error code to the 
client. It can prepare such an error before attempting the operation, so it 
will be able to produce the error message even in the case of bad_alloc.

But the discussions about move ctors that throw aren't even about bad_alloc. 
They are about assertion exceptions.

Kleopatra (KDEPIM), e.g., uses exception for assertions, precisely to be able 
to communicate a proper error code back to the client (Kleopatra is also a UI 
server). It doesn't even matter whether the program then continues to run or 
simply restarts itself. The important bit is to return that error code (and 
cancel any begun transactions) and not just drop out of the connection.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts