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