Re: Destructor call of virtual base class - what happens with exception spec?

From:

James Kanze <james.kanze@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Wed, 15 Sep 2010 02:03:33 -0700 (PDT)

Message-ID:

<fa466438-6a99-48a5-9fe9-0c9a546be884@k30g2000vbn.googlegroups.com>

On Sep 14, 9:06 pm, red floyd <redfl...@gmail.com> wrote:

On Sep 14, 2:59 am, Vladimir Jovic <vladasp...@gmail.com> wrote:

James Kanze wrote:

On Sep 13, 9:52 pm, "Balog Pal" <p...@lib.hu> wrote:

"Johannes Schaub (litb)"

[...]

Does it matter when there is so wide consensus that dtors
shall not throw?

There is wide consensus that destructors usually should not
throw. There is even wider consensus that every rule may have
exceptions, and I have at least one class whose destructor
always throws.

Sounds like a hack. Can you explain why it always throws?

I once saw something like the following nonignorable:

template<typename T>
class nonignorable {
    public:
        nonignorable(const T& t) : was_read(false), val(t) { }
        operator T() const { was_read = true; return val; }
        ~nonignorable() {
            if (!was_read)
                throw logic_error("you ignored me!");
         }
    private:
         bool was_read;
         T val;
};

The idea was to ensure that a function return value was used,
or explicitly ignored, e.g.:

nonignorable<int> somefunc()
{
    // do stuff
    return some_integer;
}

That's usually an assertion in the destructor, and not a thrown
exception. And you might want to check if the destructor is
being called before asserting---an intervening exception might
mean that it's OK not to check the return value.

--
James Kanze