From: "Wesley W. Terpstra" <terpstra@ito.tu-darmstadt.de>
To: gcc@gcc.gnu.org
Subject: Re: Warnings for unhandled c++ exceptions?
Date: Mon, 03 Feb 2003 19:16:00 -0000 [thread overview]
Message-ID: <20030203191635.GD26857@ito.tu-darmstadt.de> (raw)
On Mon, Feb 03, 2003 at 04:11:07PM -0200, Alexandre Oliva wrote:
> On Feb 3, 2003, "Wesley W. Terpstra" <terpstra@ito.tu-darmstadt.de> wrote:
>
> > I suggested an optional flag to be used for compiler-assisted bug-tracking
> > and quality code writing. (refer to the earlier portion of the message)
>
> /me thinks such a warning would be mostly useless
>
> I actually find this sad, but if you consider that most of the C++
> code out there, as well as the C library whose declarations are
> brought into C++, have no throw() declarations at all, you'd quickly
> drown into warning due to calling methods that could throw anything
> but that in reality don't, and it would be very difficult to tell what
> warnings are actually significant.
Yes, but you missed the fine print in my options' descriptions.
-Wthrow-clause-violated
If a method throws an exception which is not listed in it's
throw () clause, or calls a method whose throw clause is not
handled or not included, generate a warning.
(by not included I meant not included in our throw clause)
-Wthrow-clause-missing
If a method throws an exception or calls a method which
declares a throw clause, but has no throw-clause itself,
a warning is generated.
Implies -Wthrow-clause-violated
The first one does not warn about functions which might throw but don't
include a throw () clause. Nor does it warn about calling them.
The second will only warn about things defined within your translation unit.
... excepting inline methods of course... and I see that the libstdc++ does
this. Perhaps the above throw-clause-missing should be ignored for inlined
methods.
Therefore, these warnings will NOT be issued by including other people's
no-throw-declared headers. Only when misusing throw () declared methods and
writing bad methods yourself.
Neither warning is triggered by:
void foo(); // defined elsewhere and actually throws ints
void bar()
{
foo();
}
In a large enough software project, you probably won't be calling many of
these out-of-project methods (and such calls are suspect anyways), so the
warnings are still useful in the context you describe.
---
Wes
----- End forwarded message -----
next reply other threads:[~2003-02-03 19:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-03 19:16 Wesley W. Terpstra [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-02-03 21:37 Robert Dewar
2003-02-03 21:25 Robert Dewar
2003-02-03 19:39 Chris Lattner
2003-02-03 19:47 ` Wesley W. Terpstra
2003-02-03 20:12 ` Gabriel Dos Reis
2003-02-03 19:14 Wesley W. Terpstra
2003-02-03 15:24 Bonzini
2003-02-03 16:45 ` Wesley W. Terpstra
2003-02-03 18:13 ` Alexandre Oliva
2003-02-03 18:17 ` Gabriel Dos Reis
2003-02-03 13:13 Wesley W. Terpstra
2003-02-03 17:07 ` Joe Buck
2003-02-03 19:13 ` Mark Mielke
2003-02-03 19:24 ` Wesley W. Terpstra
2003-02-03 19:31 ` Gabriel Dos Reis
2003-02-03 19:37 ` Wesley W. Terpstra
2003-02-03 19:45 ` Phil Edwards
2003-02-03 20:08 ` Gabriel Dos Reis
2003-02-03 20:14 ` Phil Edwards
2003-02-03 20:15 ` Gabriel Dos Reis
2003-02-03 20:45 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030203191635.GD26857@ito.tu-darmstadt.de \
--to=terpstra@ito.tu-darmstadt.de \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).