This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: uw_install_context() and GDB
- From: Ian Lance Taylor <iant at google dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: Daniel Jacobowitz <drow at false dot org>, Project Archer <archer at sourceware dot org>, jason at redhat dot com
- Date: Thu, 14 Aug 2008 11:53:14 -0700
- Subject: Re: uw_install_context() and GDB
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;t=1218740012; bh=tq5PzvboCMb6gtYc6lx39UJqbKI=;h=DomainKey-Signature:To:Cc:Subject:References:From:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type; b=e4eqUg9vRE9Ib+uEANdKxUZAM6UPS+WzfKvEnbZ8SrqBzcr1O8deN9nLFp3cJB69Y3+QZhnp5577UemVcvM4mA==
- Domainkey-signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;h=to:cc:subject:references:from:date:in-reply-to:message-id:user-agent:mime-version:content-type;b=doLm9aOReTP18KacuNS615ahdkLkhqOn5i3LcZUczFkfScTzNXwpuyXhZmYXxPZAVrEU/IpNixMTnpo97WoLmw==
- References: <48A46168.7070300@redhat.com><20080814173235.GA15077@caradoc.them.org><48A47253.1060705@redhat.com>
Phil Muldoon <pmuldoon@redhat.com> writes:
> I take your point well. But if these are user-written destructors, and
> they are being executed on the journey to the exception handler,
> shouldn't "next" return control here? There is a little bit of
> irony. In a conversation I was having recently, I was making a case of
> "next" over a throw always returning control at the corresponding
> "catch", and ignoring the destructors. I changed my mind when it was
> suggested that significant and important work relevant to the code a
> user has written happen in destructors. But quite right, I glossed
> over this, and should make room for conversation on it.
I agree that "next" over a function call that throws an exception past
the current stack frame should ideally stop in a user written
destructor. It shouldn't stop for destructors in functions below the
current stack frame.
That is (the functions are not presented in the order in which they
are called):
class c { ~c(); }
void f2() {
f3(); <=== calling next here
}
void f3() {
c cv;
throw; <=== should not break here (c::~c() should run silently)
}
void f1() {
c cv;
f2(); <=== should break here on c::~c()
}
This behaviour could reasonably be made subject to something along the
lines of "handle".
Ian