lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] progress_meter dtor verifies postcondition [Was: PATCH: use std::u


From: Greg Chicares
Subject: [lmi] progress_meter dtor verifies postcondition [Was: PATCH: use std::uncaught_exceptions()]
Date: Sat, 31 Mar 2018 22:57:05 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 2018-03-29 20:18, Greg Chicares wrote:
> On 2018-03-25 16:40, Vadim Zeitlin wrote:
[...]
>> I'd still like to check for
>> uncaught_exceptions() in wxPdfDC dtor to assert (or warn?) if close()
>> hadn't been called without an active exception, as this would be a logic
>> error in this case.
[...]
> please review branch 'odd/dtor-verifies-postcondition', where
> I believe I've done what you recommend above, for the progress_meter
> class. The dtor notifies us whenever we've followed an execution
> path that doesn't call culminate() as it should (which would be a
> logic error).

Your reply didn't object to this, so I've cherry-picked it into
production after reviewing it again carefully myself. It doesn't
actually affect production code AFAICT--the former mere warning
in culminate() has never been reported and is highly likely to be
unreachable as presently used, so making it an error instead is
quite safe. But, if it does occur, it actually does represent an
error.

Treating it as an error makes it safer to use this class in other
ways in the future. By its nature, it insinuates itself into inner
loops of code that uses it, and I do remember therefore fretting
over whether I had called culminate() exactly where necessary in
run_census_in_parallel::operator().

I was also bothered by this (removed) commentary:

-/// it now. Postcondition failure engenders only a warning because
-/// of other possibilities--e.g., a loop might throw an exception
-/// inside a try-block whose catch-clause doesn't rethrow; perhaps it
-/// would be better to throw an exception instead, depending on the
-/// value of a boolean argument.

Issuing only a warning because I seemingly didn't want to think
through all the ramifications was just a mistake. Switching
between a warning and an error based on an extra argument would
be a further mistake: that simply means allowing end users to
override certain errors.

I'll push this and delete branch 'odd/dtor-verifies-postcondition'
soon.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]