Some more thoughts:
It seems the link you sent also suggests not to use it:
http://www.gotw.ca/gotw/047.htm
"Unfortunately, I do not know of any good and safe use for
std::uncaught_exception. My advice: Don't use it."
Also worth mentioning, the c2wiki page suggests that
std::uncaught_exception doesn't work properly in some versions of MSVC.
>> 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.
The best solution is to refactor the objects at hand, but that is quite a
bit of work in some cases. The try {...} catch(...) { ... logging ... } at
least prevents the crash and gives a clear error message to report. I think
we should be able to fix all of these for 1.14 and / or whenever we
transition to C++11 / C++14.
We could contemplate backporting fixes to 1.12 but I would be a bit leery
of rewriting "save_blocker" and backporting it for instance. I would think
that it would be a lot of work to test a new implementation enough to be
sure that it should go into the stable version, so I personally don't have
plans to do something like that unless it goes through a beta phase.
Best Regards,
Chris Beck
On Tue, Dec 16, 2014 at 11:38 PM, chris beck <beck...@gmail.com> wrote:
>
> > Could you point me to that discussion?
>
> https://mail.gna.org/public/wesnoth-dev/2014-06/msg00006.html
>
> > Of course it is also
> possible to use std::uncaught_exception but whether that is a good idea
> is open for discussion
>
> I had thought that we had settled this discussion in June, since no one
> disagreed with Dave. But if you'd like to reopen this we can.
>
> However, IMO it's better to just ban throwing destructors, it seems to just
> add needless complication, uglifies the code and makes it less
> accessible to beginners, and should never be necessary.
>
> There are many pitfalls listed on this page (and the blog post that I
> linked
> earlier) to trying to use std::uncaught exception to handle throwing
> dtors,
> it may behave in a way that is unexpected once the code becomes more
> complicated than toy examples:
> http://c2.com/cgi/wiki?BewareOfExceptionsInTheDestructor
>
> Best Regards,
> Chris Beck
>
> On Mon, Dec 15, 2014 at 3:26 PM, Mark de Wever <ko...@xs4all.nl> wrote:
>>
>> 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
>>
>
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
