Re: Warnings for unhandled c++ exceptions?

Re: Warnings for unhandled c++ exceptions?

[Bonzini]

> int foo() throw (int)
> {
>     throw "this will abort -- why? I broke my promise, but no warning...";
> }
> ...
> catch (const char *s)

A warning might be desirable, but it is not an odd behavior, as the purpose
of the throw clause (aka exception specification) is exactly to abort if an
exception that's not mentioned there propagates above it.

"Whenever an exception is thrown and the search for a handler (15.3)
encounters the outermost block of a function with an
exception-specification, the function unexpected() is called (15.5.2) if the
exception-specification does not allow the exception. (15.4.8)."

"exception handling must be abandoned [...] when unexpected() throws an
exception which is not allowed by the previously violated
exception-specification, and std::bad_exception is not included in that
exception-specification." (15.5.1.1) "In such cases, void terminate(); is
called." (15.5.1.2)

Anyway I don't think the warning should be enabled by default as wide bodies
of C++ code don't use exception specifications.

Paolo

Re: Warnings for unhandled c++ exceptions?

[Wesley W. Terpstra]

On Mon, Feb 03, 2003 at 12:34:06PM +0100, Bonzini wrote:
> > int foo() throw (int)
> > {
> >     throw "this will abort -- why? I broke my promise, but no warning...";
> > }
> > ...
> > catch (const char *s)
> 
> A warning might be desirable, but it is not an odd behavior, as the purpose
> of the throw clause (aka exception specification) is exactly to abort if an
> exception that's not mentioned there propagates above it.

Ahh. That makes sense. That is at least some guarantee.

> Anyway I don't think the warning should be enabled by default as wide bodies
> of C++ code don't use exception specifications.

I never suggested is as a default.

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)

... especially since most (all?) of these errors are visible at compile-time.

Perhaps there should be two flags:

	-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.
	-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

I only suggest this if some does not already have a patch floating around.
I presume someone else has already requested this functionality?
google didn't turn up much because the keywords are ambiguous.

---
Wes

Re: Warnings for unhandled c++ exceptions?

[Alexandre Oliva]

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.

> I presume someone else has already requested this functionality?

Yup.  Searching the mailing list will, with some luck for picking the
right search terms, find a number of similar requests.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Warnings for unhandled c++ exceptions?

[Gabriel Dos Reis]

Alexandre Oliva <aoliva@redhat.com> writes:

[...]

| > I presume someone else has already requested this functionality?
| 
| Yup.  Searching the mailing list will, with some luck for picking the
| right search terms, find a number of similar requests.

Plus some lengthy discussions in C++ newsgroups (to understand why C++
exception model is fundamentally different from that of Java).

-- Gaby

Re: Warnings for unhandled c++ exceptions?

[Robert Dewar]

> The FSF and RMS have some psychological hangup with calling code "legal" or
> "illegal".  (My own opinion is that, as long as the ISO language standard
> uses it, RMS can take a leap.)

Note that "legal" is also a very well defined technical term in Ada, and
it would be actively confusing to use any ill-defined term in its place
when discussing Ada programs.

Re: Warnings for unhandled c++ exceptions?

[Robert Dewar]

I think it is a bad idea to put in this warning. There are good and valid
arguments on both sides of this issue. Ada and C++ have both decided (after
a discussion in which the merits of both sides were fully understood) decided
to go one way, Java (which may or may not have been subject to a similar
carefully considered argument, who knows?) decided to go the other way. It
is inappropriate to have a compiler second guess this decision.

Re: Warnings for unhandled c++ exceptions?

[Andreas Schwab]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

|> Phil Edwards <phil@jaj.com> writes:
|> 
|> | On Mon, Feb 03, 2003 at 09:08:13PM +0100, Gabriel Dos Reis wrote:
|> | > Phil Edwards <phil@jaj.com> writes:
|> | > 
|> | > | On Mon, Feb 03, 2003 at 08:37:00PM +0100, Wesley W. Terpstra wrote:
|> | > | > Because I was reading the C++ FAQ LITE yesterday. :-)
|> | > | > I thought his definitions were apt.
|> | > | > They are strong words though; maybe I should drop them.
|> | > | 
|> | > | The FSF and RMS have some psychological hangup with calling code "legal" or
|> | > | "illegal".  (My own opinion is that, as long as the ISO language standard
|> | > | uses it, RMS can take a leap.)
|> | > 
|> | > C++ definition does not use such strong words.  Rather, it speaks of 
|> | > "well-formed"/"ill-formed" program constructs.
|> | 
|> | I don't recall where, but a text search of the standard will show otherwise.
|> 
|> If you find such things, then you're encouraged to fill a due DR
|> against the C++ definition.  Really.

The only occurence of "illegal" that I could find is in [diff.dcl].  There
are also two occurences of "legal" in a footnote of [class.virtual] and in
[diff.decl].  Anyone for a DR?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Warnings for unhandled c++ exceptions?

[Gabriel Dos Reis]

Phil Edwards <phil@jaj.com> writes:

| On Mon, Feb 03, 2003 at 09:08:13PM +0100, Gabriel Dos Reis wrote:
| > Phil Edwards <phil@jaj.com> writes:
| > 
| > | On Mon, Feb 03, 2003 at 08:37:00PM +0100, Wesley W. Terpstra wrote:
| > | > Because I was reading the C++ FAQ LITE yesterday. :-)
| > | > I thought his definitions were apt.
| > | > They are strong words though; maybe I should drop them.
| > | 
| > | The FSF and RMS have some psychological hangup with calling code "legal" or
| > | "illegal".  (My own opinion is that, as long as the ISO language standard
| > | uses it, RMS can take a leap.)
| > 
| > C++ definition does not use such strong words.  Rather, it speaks of 
| > "well-formed"/"ill-formed" program constructs.
| 
| I don't recall where, but a text search of the standard will show otherwise.

If you find such things, then you're encouraged to fill a due DR
against the C++ definition.  Really.

-- Gaby

Re: Warnings for unhandled c++ exceptions?

[Phil Edwards]

On Mon, Feb 03, 2003 at 09:08:13PM +0100, Gabriel Dos Reis wrote:
> Phil Edwards <phil@jaj.com> writes:
> 
> | On Mon, Feb 03, 2003 at 08:37:00PM +0100, Wesley W. Terpstra wrote:
> | > Because I was reading the C++ FAQ LITE yesterday. :-)
> | > I thought his definitions were apt.
> | > They are strong words though; maybe I should drop them.
> | 
> | The FSF and RMS have some psychological hangup with calling code "legal" or
> | "illegal".  (My own opinion is that, as long as the ISO language standard
> | uses it, RMS can take a leap.)
> 
> C++ definition does not use such strong words.  Rather, it speaks of 
> "well-formed"/"ill-formed" program constructs.

I don't recall where, but a text search of the standard will show otherwise.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: Warnings for unhandled c++ exceptions?

[Gabriel Dos Reis]

"Wesley W. Terpstra" <terpstra@ito.tu-darmstadt.de> writes:

| On Mon, Feb 03, 2003 at 01:41:54PM -0600, Chris Lattner wrote:
| > 
| > > My primary goals for this warning were solely: bug tracking and
| > > consistency verification. Nothing more.
| > ...
| > > 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.
| > 
| > Remember that one of the major problems with C++ exception specifications
| > is that they basically can't work with generic code.  For example, if you
| > had a throw clause on your copy ctor, you couldn't use an std::vector of
| > your class without getting a warning (because the code calling the copy
| > ctor doesn't have an exception specification).
| 
| That is very true. I had not considered this.
| 
| However, I think this can be remedied in the same way that offending inline
| methods can be: pretend they are part of the method which instantiates or
| inlines them.

If you can pretend that, then you can just pretend that you don't
violate ES.  As you might realize, C++ exception mechanism is not a
copy-n-paste of Java model -- in some sens, they are quite opposite.
I believe, that any argument that departs from "Java does ES like this
so C++ should do the same" will have hard time to convince me.

-- Gaby

Re: Warnings for unhandled c++ exceptions?

[Gabriel Dos Reis]

Phil Edwards <phil@jaj.com> writes:

| On Mon, Feb 03, 2003 at 08:37:00PM +0100, Wesley W. Terpstra wrote:
| > Because I was reading the C++ FAQ LITE yesterday. :-)
| > I thought his definitions were apt.
| > They are strong words though; maybe I should drop them.
| 
| The FSF and RMS have some psychological hangup with calling code "legal" or
| "illegal".  (My own opinion is that, as long as the ISO language standard
| uses it, RMS can take a leap.)

C++ definition does not use such strong words.  Rather, it speaks of 
"well-formed"/"ill-formed" program constructs.

-- Gaby
 

Re: Warnings for unhandled c++ exceptions?

[Wesley W. Terpstra]

On Mon, Feb 03, 2003 at 01:41:54PM -0600, Chris Lattner wrote:
> 
> > My primary goals for this warning were solely: bug tracking and
> > consistency verification. Nothing more.
> ...
> > 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.
> 
> Remember that one of the major problems with C++ exception specifications
> is that they basically can't work with generic code.  For example, if you
> had a throw clause on your copy ctor, you couldn't use an std::vector of
> your class without getting a warning (because the code calling the copy
> ctor doesn't have an exception specification).

That is very true. I had not considered this.

However, I think this can be remedied in the same way that offending inline
methods can be: pretend they are part of the method which instantiates or
inlines them.

The instantiating method should be the one to declare the throw ().

> Note that this is just an example, even if you don't have throw'ing copy
> ctors it can come up in other cases as well... With any amount of generic
> code used, I can't imagine how this would be practical at all.

Yes, quite true. There are many cases.
However, propogating the responsibility up would work I think.

Hmmm... Although taking pointers to static methods in template-code presents
a problem. That needs some thought.

This warning would be absolute hell if we let code
	void _throw_failure() const { throw new ios::failure(this); }
(from libstdc++) warn.

So, maybe kill two birds with one stone? ... and keep the guarantees.

---
Wes

Re: Warnings for unhandled c++ exceptions?

[Phil Edwards]

On Mon, Feb 03, 2003 at 08:37:00PM +0100, Wesley W. Terpstra wrote:
> Because I was reading the C++ FAQ LITE yesterday. :-)
> I thought his definitions were apt.
> They are strong words though; maybe I should drop them.

The FSF and RMS have some psychological hangup with calling code "legal" or
"illegal".  (My own opinion is that, as long as the ISO language standard
uses it, RMS can take a leap.)


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: Warnings for unhandled c++ exceptions?

[Chris Lattner]

> My primary goals for this warning were solely: bug tracking and
> consistency verification. Nothing more.
...
> 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.

Remember that one of the major problems with C++ exception specifications
is that they basically can't work with generic code.  For example, if you
had a throw clause on your copy ctor, you couldn't use an std::vector of
your class without getting a warning (because the code calling the copy
ctor doesn't have an exception specification).

Note that this is just an example, even if you don't have throw'ing copy
ctors it can come up in other cases as well... With any amount of generic
code used, I can't imagine how this would be practical at all.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/

Re: Warnings for unhandled c++ exceptions?

[Wesley W. Terpstra]

On Mon, Feb 03, 2003 at 08:31:12PM +0100, Gabriel Dos Reis wrote:
> "Wesley W. Terpstra" <terpstra@ito.tu-darmstadt.de> writes:
> 
> | There are lots of warnings for behaviours that are *legal* C++ but
> | unethical. 
> 
> These words ("legal", "unethical") sound wrong to me.  Right now
> you're the first person using them in this discussion.  I don't know
> why... 

Because I was reading the C++ FAQ LITE yesterday. :-)
I thought his definitions were apt.
They are strong words though; maybe I should drop them.

What the FAQ meant with them is:
	legal = syntactically correct and valid C++
	        that also won't segfault, break, etc
	unethical = code that is fragile with respect to aging

eg:	if (x = y) { ... } is legal code
but, unethical

I will stop using them; I thought that perhaps their use was more widespread
than that fellows page. Plus -- there are terse and (with the above
definitions) precise.

---
Wes

Re: Warnings for unhandled c++ exceptions?

[Gabriel Dos Reis]

"Wesley W. Terpstra" <terpstra@ito.tu-darmstadt.de> writes:

| There are lots of warnings for behaviours that are *legal* C++ but
| unethical. 

These words ("legal", "unethical") sound wrong to me.  Right now
you're the first person using them in this discussion.  I don't know
why... 

-- Gaby

Re: Warnings for unhandled c++ exceptions?

[Wesley W. Terpstra]

On Mon, Feb 03, 2003 at 02:21:41PM -0500, Mark Mielke wrote:
> On Mon, Feb 03, 2003 at 02:13:45PM +0100, Wesley W. Terpstra wrote:
> > I find this feature of Java remarkably useful as it helps to detect sloppy
> > exception handling, which is brutal to find in C++. I do not desire to
> > change the C++ language much; I like it just how it is, but I think an
> > optional warning would be useful during development under g++.
> 
> Even in Java, they recognized that sometimes, this ability, is more trouble
> than it is worth. Consider sub classes of java.lang.RuntimeException.

Indeed, but as you might notice, my proposal does not make 'runtime'
exceptions (such as 'new' runs out of memory) and many other cases generate
a warning. If it is not an exception explicitly thrown or explicitly listed
in a called function's throw clause, the warning is not triggered. So
division by zero, etc, or anything hidden by a library is not warned.

Plus, the warning is entirely optional and not default.

> I don't think there is a 'right' answer to this problem. Java leans towards
> one side, while C++ leans towards the other side. It seems wrong to me to
> encourage C++ users to lean the wrong way by presenting them with a 'Java'
> style warning. C++ users need to be familiar with C++ practices. If they
> are not, they will never excel at C++.

I did not mean to imply that people should not use and know C++ practices.
There are lots of warnings for behaviours that are *legal* C++ but
unethical. And this warning is not something I would suggest including in
-Wall.

My primary goals for this warning were solely: bug tracking and consistency
verification. Nothing more.

I have no designs to change the exception paradigm of C++.

> I would be against such a warning message. It is cute, but impractical.

I disagree that it is impracticle. With a really large project, consistency
of throw can be really hard to verify.

---
Wes

Re: Warnings for unhandled c++ exceptions?

[Wesley W. Terpstra]

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 -----

Re: Warnings for unhandled c++ exceptions?

[Wesley W. Terpstra]

On Mon, Feb 03, 2003 at 09:05:59AM -0800, Joe Buck wrote:
> On Mon, Feb 03, 2003 at 02:13:45PM +0100, Wesley W. Terpstra wrote:
> > Is there a compiler flag for g++ which would warn on these code snippets:
> > 
> > 1.
> > 
> > void foo()
> > {
> > 	throw 4;
> > }
> > 
> > Warning: Exception 'int' must be caught, or it must be declared in throw ()
> > clause of this method.
> 
> But there is no such requirement in C++.  If there is no throw() directive,
> it means that anything can be thrown.

I understand this, but it would still be useful to have an option to track
bugs. No one is forced to use this option, and those who choose to say:
	'the above code is unethical' can write better code

> > I find this feature of Java remarkably useful as it helps to detect sloppy
> > exception handling, which is brutal to find in C++. I do not desire to
> > change the C++ language much; I like it just how it is, but I think an
> > optional warning would be useful during development under g++.
> 
> Any such option cannot use the word "must", because it implies a language
> requirement that is not present.

Ok, fair enough, how about "This option helps detect unhandled exceptions by
reporting violations of an extra-language constraint that all throwable
exceptions should be declared in the prototype".

And a warning like

"Warning: method can throw an exception undeclared in it's prototype, and
you said you didn't want this to be allowed."

> What you're seeing below is standard C++ behavior.  If a function
> declares that it will only throw int, but it throws something else,
> it immediately terminates.  That's the way C++ assures that promises
> like throw(int) are kept.

Someone pointed this out already. That was a misunderstanding of mine.
(I actually expected gcc to try to convert the const char* to int)

---
Wes

Re: Warnings for unhandled c++ exceptions?

[Mark Mielke]

On Mon, Feb 03, 2003 at 02:13:45PM +0100, Wesley W. Terpstra wrote:
> I find this feature of Java remarkably useful as it helps to detect sloppy
> exception handling, which is brutal to find in C++. I do not desire to
> change the C++ language much; I like it just how it is, but I think an
> optional warning would be useful during development under g++.

Even in Java, they recognized that sometimes, this ability, is more trouble
than it is worth. Consider sub classes of java.lang.RuntimeException.

I don't think there is a 'right' answer to this problem. Java leans towards
one side, while C++ leans towards the other side. It seems wrong to me to
encourage C++ users to lean the wrong way by presenting them with a 'Java'
style warning. C++ users need to be familiar with C++ practices. If they
are not, they will never excel at C++.

I would be against such a warning message. It is cute, but impractical.

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: Warnings for unhandled c++ exceptions?

[Joe Buck]

On Mon, Feb 03, 2003 at 02:13:45PM +0100, Wesley W. Terpstra wrote:
> Is there a compiler flag for g++ which would warn on these code snippets:
> 
> 1.
> 
> void foo()
> {
> 	throw 4;
> }
> 
> Warning: Exception 'int' must be caught, or it must be declared in throw ()
> clause of this method.

But there is no such requirement in C++.  If there is no throw() directive,
it means that anything can be thrown.
 
> I find this feature of Java remarkably useful as it helps to detect sloppy
> exception handling, which is brutal to find in C++. I do not desire to
> change the C++ language much; I like it just how it is, but I think an
> optional warning would be useful during development under g++.

Any such option cannot use the word "must", because it implies a language
requirement that is not present.  
 
> Relatedly, I'm sure you are aware of this odd behaviour:
> 	(debian gcc 3.2.2-0pre5)

You should be aware of this odd behavior, too, if you want to pass yourself
off as a C++ programmer. :-)

What you're seeing below is standard C++ behavior.  If a function
declares that it will only throw int, but it throws something else,
it immediately terminates.  That's the way C++ assures that promises
like throw(int) are kept.
 
> int foo() throw (int)
> {
> 	throw "this will abort -- why? I broke my promise, but no warning...";
> }
> 
> int main()
> {
> 	try
> 	{
> 		foo();
> 	}
> 	catch (const char* s)
> 	{
> 		// should catch here...
> 	}
> 	catch (int x)
> 	{
> 		// in case of a weird conversion
> 	}
> 	return 0;
> }
> 
> ----------------------------
> 
> Thanks for your time.
> 
> ---
> Wes

-- 
Q. What's more of a headache than a bug in a compiler.
A. Bugs in six compilers.  -- Mark Johnson

Warnings for unhandled c++ exceptions?

[Wesley W. Terpstra]

Is there a compiler flag for g++ which would warn on these code snippets:

1.

void foo()
{
	throw 4;
}

Warning: Exception 'int' must be caught, or it must be declared in throw ()
clause of this method.

2.

void foo() throw (int)
{
	throw 4;
}

void bar()
{
	foo();
}

Warning: ... bar ... 'int' must be caught or ...

----------------------------

I find this feature of Java remarkably useful as it helps to detect sloppy
exception handling, which is brutal to find in C++. I do not desire to
change the C++ language much; I like it just how it is, but I think an
optional warning would be useful during development under g++.

Since g++ can also invoke Java methods, and in turn be called by them, it
also makes sense that g++ should be able to maintain the Java-style
guarantees about only throwing what one declares throwable.

Is there some undocumented -W option to turn this warning on?
Is there some patch someone has I can apply to add this feature?
And if not ... shouldn't there be?

----------------------------

Relatedly, I'm sure you are aware of this odd behaviour:
	(debian gcc 3.2.2-0pre5)

int foo() throw (int)
{
	throw "this will abort -- why? I broke my promise, but no warning...";
}

int main()
{
	try
	{
		foo();
	}
	catch (const char* s)
	{
		// should catch here...
	}
	catch (int x)
	{
		// in case of a weird conversion
	}
	return 0;
}

----------------------------

Thanks for your time.

---
Wes