------- Comment #33 from hhinnant at apple dot com 2006-01-12 02:49 -------
(In reply to comment #32)
> As I said before, there is still a diagnostic issue and now it is worse
> with
> doing that in the front-end since people don't read docs that well so
> we will
> be getting bug reports about try/catch not doing the correct thing when
> -fno-exceptions is supplied (yes I am serious).
Yes, excellent point. Let's back up a minute:
What do we want to happen for this program (under -fno-exceptions)?
int main()
{
try
{
}
catch (...)
{
}
}
?
My recommendation would be something along the lines of:
error: exception handling disabled, use -fexceptions to enable
(which is what currently happens, good job all around).
Now: what do we want to happen for this program:
#include <vector>
int main()
{
try
{
}
catch (...)
{
}
}
?
My recommendation: Same as the last program. Today's results: Compiles with
no diagnostic.
I don't think this is the best quality that we can offer, mainly due to the
difference in behavior by merely including <vector>.
So it comes back to the first example: What is the best solution for the
customer if try/catch is used with -fno-exceptions? Perhaps I am wrong that an
error is best? What do other compilers do in this situation?
EDG:
"ComeauTest.c", line 3: error: support for exception handling is disabled
try
^
CodeWarrior:
Error : exception handling option is disabled
HelloWorld.cp line 4 {
If I'm wrong about a diagnostic being preferrable, I'm in good company. And
both of these products give the same result if <vector> is included.
If there is to be a front end fix, it would have to be special for #pragma GCC
system_header. Just seems like a lot of fuss just so you can read "try"
instead of "__try" in a libstdc++ header. But I have no objection to someone
fixing the front end that way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
