On Sat, Dec 06, 2014 at 12:45:51AM -0500, chris beck wrote:
> Just another followup on this:
>
> An additional barrier that hasn't been mentioned has to do with exceptions
> and destructors in our code. Previously we had a discussion on the list
> about destructors throwing exceptions -- it seems that wesnoth has many
> classes with destructors which are designed to throw exceptions, presumably
> because some developers didn't fully understand the C++ rules about this.
Could you point me to that discussion?
> In C++98, a destructor may throw an exception but
> - children of the class may not be destroyed properly and their memory
> leaked
> - if the destructor was called during "stack unwinding" from an earlier
> exception, the program is immediately terminated.
So this means the behaviour already is a bug. AFAIK there is one
occurence of this behaviour in
ana/api/binary_streams.hpp:328
But that code is unused AFAIK.
> After the first email thread, I went through many of the destructors and
> wrapped them in "try { ... } catch (...) { } " blocks to prevent crashes.
> (or "try {...} catch (...) { ... logging ... }" )
Which is also not a great solution. I fear the cause might be that the
destructor needs to do too much things to undo. Of course it is also
possible to use std::uncaught_exception, but whether that is a good idea
is open for discussion [1].
[1] http://www.gotw.ca/gotw/047.htm
--
Regards,
Mark de Wever aka Mordante/SkeletonCrew
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
