Re: May I propose an extension and ask how difficult this would be?

[George Talbot <george at moberg dot com>]

On Sat, 20 Nov 1999, Phil Edwards wrote:

> > Now that I'm done ranting, do the people who think it's a failed idea have
> > a better suggestion?  This seems to work with great elegance and utility
> > in Java.
> 
> That's because in Java, exceptions cannot appear outside the Java code and
> propogate in.  But in C++,
> 
>     extern "C"  void somefunc();
>     void foo()  throw (stuff) {
>         // buncha code
>         somefunc();
>         // bunch more code
>     }
>
> nothing prevents somefunc() from throwing an exception that isn't "stuff"
> as somefunc() doesn't have to be written in C.

I think that if you're linking to external code, then you probably
declared it like this:

	extern "C" void somefunc() throw (this, that, the, other);
	void foo() throw (stuff, this, that)
	{
		//buncha code
		try
		{
			somefunc();
		}
		catch (the)
		{
			oh();
		}
		catch (other)
		{
			no();
		}
		//buncha code
	}

Point being that if you want to use a warning implementing mandatory
exception specifications, then you probably will go to the trouble of
determining what is thrown by external code.  If you miss some, oh
well... ;^)

>  If I recall Stroustrup
> correctly, this is one of the reasons that automatic-exception-specifications
> were not added.  Other languages become involved.
> 
> (How common that actually is, I have no clue.  But I think that's the
> reasoning.  Sanity check?)

That would make sense.  I still think a compiler warning is a good idea,
though.

> As far as increased optomized possiblilties go, remember that exception
> specifications carry a penalty of their own:  the extra code generated
> (space) and executed (time) during that function call at runtime, to check
> that the exception being thrown is on the approved list.  Any optomizations
> you might get out of the specs would have to overcome those penalties before
> "paying for themselves".
> 
> (And if you argue that the thrown exception is so rare that the extra
> checking code isn't a penalty, then I have to ask:  if you expect exceptions
> in that function /that/ rarely, why are you adding a specification?  :-)

I didn't really want optimization, I wanted the compiler to sanity-check
me when I write exception handling code.  Having the compiler do this
check is what makes exceptions practical in Java, and I think that
exceptions in C++ would be much more practical if this feature were added.

All that said, does anyone have a clue how hard this would be to add?
Does anyone know enough to point me to the right place to try to implement
an experimental patch?

> > Java:
> > 	+ Garbage Collection
> > 	+ Exceptions are easy to implement
> >
> > C++:
> > 	+ Parameterized types
> > 	+ Fast compiled code
> 
> Nothing prevents you from adding "Garbage Collection" to the C++ list.  Just
> because it isn't built-in to the language doesn't mean it's not possible or
> already implemented.  But you knew that already, I'm just babbling now...

I actually thought a lot about using one of the existing garbage
collection packages for C++, but I chickened out, as I've got a
multithreaded program and I worried about whether I could find one that
would work well in such a program.

--
George T. Talbot
<george@moberg.com>