Boost logo

Boost :

From: Sean Corfield (sean.corfield_at_[hidden])
Date: 1999-07-09 12:04:56

On Wednesday, July 07, 1999 8:56 PM, Reid Sweatman [SMTP:reids_at_[hidden]]
> Basically, I guess I'm asking whether you, or anyone else (make sure 'e
> doesn't leave the room...<sorry<g>>) can point me to a book or other

"Is it alright if we go with him?"

> that discusses this issue. It seems to me that without the decoration,
> function *could* throw, and without that compiler-generated excess
> you wouldn't even get an unexpected exception, leaving it to a higher
> function to catch. Unfortunately, since the function was assumed not to
> throw, that higher function probably wouldn't know what to do with the
> exception. Comments?

If the function is not decorated, then you should assume it can (and will)
throw exceptions. Part of the problem is that compilers don't (currently)
check exception specifications. The committee are considering a change (in
the distant future!) to make exception specifications part of the type
system which would allow compilers to do more stringent checking - much in
the style of Java.

For now, I'd leave your "throw()" specs in there. If your functions call
something that can throw exceptions, your function should check and handle
such exceptions.

Sean A Corfield                            fax:+441252654077
Technical Director                      tel/sms:+44385758805
Object Consultancy Services Ltd
"If you're not annoying somebody, you're not really alive."
                                           - Margaret Atwood
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they   
are addressed. If you have received this email in error please notify 
the system manager.
This footnote also confirms that this email message has been swept by 
MIMEsweeper for the presence of computer viruses.
------------------------------------------------------------------------ home: - Simplifying group communications

Boost list run by bdawes at, gregod at, cpdaniel at, john at