The following example is a simple C++ exception handling program. It works
fine.
However, if I try to throw the exception by a math error, it crashes.
Any suggestions?
Thanks
Markus
#include <iostream.h>
#include <math.h>
class MyException
{
};
int matherr(_exception *error) throw(MyException)
{
static MyException exception;
cout << “Mathematical error” << endl;
throw exception;
}
int main()
{
try
{
//double a = sqrt(-1); // This crashes
matherr(0); // This works fine
}
catch (MyException exception)
{
cout << “Exception caught!” << endl;
}
return 0;
}
It’s because our libm wasn’t compiled with -fexceptions, and the
throw is trying to unwind the stack back through this code. Since it
can’t find exception frame information, it aborts.
I recompiled libm with -fexceptions, and your example now works. However
I doubt that we will ever ship a version with exceptions, since it adds
considerably to the size of the library.
Markus Loffler <loffler@ces.clemson.edu> wrote:
The following example is a simple C++ exception handling program. It works
fine.
However, if I try to throw the exception by a math error, it crashes.
Any suggestions?
Thanks
Markus
#include <iostream.h
#include <math.h
class MyException
{
};
int matherr(_exception *error) throw(MyException)
{
static MyException exception;
cout << “Mathematical error” << endl;
throw exception;
}
int main()
{
try
{
//double a = sqrt(-1); // This crashes
matherr(0); // This works fine
}
catch (MyException exception)
{
cout << “Exception caught!” << endl;
}
return 0;
}
–
cburgess@qnx.com
Thanks Colin.
Does the -fexceptions option only add a overhead in size to the library, or
is there also a disadvantage in execution speed?
Markus
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:95pd95$ljn$1@nntp.qnx.com…
It’s because our libm wasn’t compiled with -fexceptions, and the
throw is trying to unwind the stack back through this code. Since it
can’t find exception frame information, it aborts.
I recompiled libm with -fexceptions, and your example now works. However
I doubt that we will ever ship a version with exceptions, since it adds
considerably to the size of the library.
Markus Loffler <> loffler@ces.clemson.edu> > wrote:
The following example is a simple C++ exception handling program. It
works
fine.
However, if I try to throw the exception by a math error, it crashes.
Any suggestions?
Thanks
Markus
#include <iostream.h
#include <math.h
class MyException
{
};
int matherr(_exception *error) throw(MyException)
{
static MyException exception;
cout << “Mathematical error” << endl;
throw exception;
}
int main()
{
try
{
//double a = sqrt(-1); // This crashes
matherr(0); // This works fine
}
catch (MyException exception)
{
cout << “Exception caught!” << endl;
}
return 0;
}
\
cburgess@qnx.com
I think it will add overhead in both senses, but nonetheless the version
with exception must be available for those who need it. Why don’t you
let us decide what to use Colin?
Markus Loffler wrote:
Thanks Colin.
Does the -fexceptions option only add a overhead in size to the library, or
is there also a disadvantage in execution speed?
Markus
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:95pd95$ljn$> 1@nntp.qnx.com> …
It’s because our libm wasn’t compiled with -fexceptions, and the
throw is trying to unwind the stack back through this code. Since it
can’t find exception frame information, it aborts.
I recompiled libm with -fexceptions, and your example now works. However
I doubt that we will ever ship a version with exceptions, since it adds
considerably to the size of the library.
Markus Loffler <> loffler@ces.clemson.edu> > wrote:
The following example is a simple C++ exception handling program. It
works
fine.
However, if I try to throw the exception by a math error, it crashes.
Any suggestions?
Thanks
Markus
#include <iostream.h
#include <math.h
class MyException
{
};
int matherr(_exception *error) throw(MyException)
{
static MyException exception;
cout << “Mathematical error” << endl;
throw exception;
}
int main()
{
try
{
//double a = sqrt(-1); // This crashes
matherr(0); // This works fine
}
catch (MyException exception)
{
cout << “Exception caught!” << endl;
}
return 0;
}
\
cburgess@qnx.com
Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
I think it will add overhead in both senses, but nonetheless the version
with exception must be available for those who need it.
Well, it adds bloat in terms of the data segment, since the exception
unwind information is loaded and relocated at runtime. This information
also cannot be shared, so in the case of libm, that’s another 11k of non
shared data, which will not be used in the majority of cases.
Why don’t you
let us decide what to use Colin?
When we open the source, then you’ll be able to comipile it however you
want, Igor.
Markus Loffler wrote:
Thanks Colin.
Does the -fexceptions option only add a overhead in size to the library, or
is there also a disadvantage in execution speed?
Markus
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:95pd95$ljn$> 1@nntp.qnx.com> …
It’s because our libm wasn’t compiled with -fexceptions, and the
throw is trying to unwind the stack back through this code. Since it
can’t find exception frame information, it aborts.
I recompiled libm with -fexceptions, and your example now works. However
I doubt that we will ever ship a version with exceptions, since it adds
considerably to the size of the library.
Markus Loffler <> loffler@ces.clemson.edu> > wrote:
The following example is a simple C++ exception handling program. It
works
fine.
However, if I try to throw the exception by a math error, it crashes.
Any suggestions?
Thanks
Markus
#include <iostream.h
#include <math.h
class MyException
{
};
int matherr(_exception *error) throw(MyException)
{
static MyException exception;
cout << “Mathematical error” << endl;
throw exception;
}
int main()
{
try
{
//double a = sqrt(-1); // This crashes
matherr(0); // This works fine
}
catch (MyException exception)
{
cout << “Exception caught!” << endl;
}
return 0;
}
\
cburgess@qnx.com
–
cburgess@qnx.com
Hi Colin,
I agree. Those of us that know how to use exceptions, NEED EXCEPTIONS. And
if that means that the libraries must be compiled with -fexceptions then we
NEED -fexceptions. It’s not a maybe.
Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote in message
news:3A8044A6.DB1E8153@motorola.com…
I think it will add overhead in both senses, but nonetheless the version
with exception must be available for those who need it. Why don’t you
let us decide what to use Colin?
Markus Loffler wrote:
Thanks Colin.
Does the -fexceptions option only add a overhead in size to the library,
or
is there also a disadvantage in execution speed?
Markus
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:95pd95$ljn$> 1@nntp.qnx.com> …
It’s because our libm wasn’t compiled with -fexceptions, and the
throw is trying to unwind the stack back through this code. Since it
can’t find exception frame information, it aborts.
I recompiled libm with -fexceptions, and your example now works.
However
I doubt that we will ever ship a version with exceptions, since it
adds
considerably to the size of the library.
When we open the source, then you’ll be able to comipile it however you
want, Igor.
I’m OK with that. When is the source being opened ?
I certainly believe that if people are wanting to do C++ development, having
malfunctioning exceptions will quickly start to become a burden. I know in
our case, the overhead for exceptions is certainly not too high a price to
pay for the code clarity they allow. I can certainly see how this would not
be the case for small targets, and I have no problem with that being the
default, and those who want exceptions having to re-compile with exceptions
enabled; however, I do think that people are going to need access to this
pretty quickly (I know that our stuff will quickly be getting big enough
that properly working exceptions - through all the standard libs - is going
to be necessary).
Rennie
Bill at Sierra Design <BC@sierradesign.com> wrote:
Hi Colin,
I agree. Those of us that know how to use exceptions, NEED EXCEPTIONS. And
if that means that the libraries must be compiled with -fexceptions then we
NEED -fexceptions. It’s not a maybe.
The only case where C++ users lose without having the exceptions versions
of C libraries is if they throw an exception from a callback function
that was called from non-exception code. This is a very rare case, and
I don’t think it justifies adding 10-15% more data per process for this
case.
–
cburgess@qnx.com
Colin Burgess wrote:
Bill at Sierra Design <> BC@sierradesign.com> > wrote:
Hi Colin,
I agree. Those of us that know how to use exceptions, NEED EXCEPTIONS. And
if that means that the libraries must be compiled with -fexceptions then we
NEED -fexceptions. It’s not a maybe.
The only case where C++ users lose without having the exceptions versions
of C libraries is if they throw an exception from a callback function
that was called from non-exception code. This is a very rare case, and
I don’t think it justifies adding 10-15% more data per process for this
case.
Why can’t you have libmex.so and have your qcc to link against it when
-fexceptions (or whatever equivalent you invent for it) is specified?
‘When we open the source’ is not a good answer for those who need it
now/soon, because you’re talking about opening source for a full year
already and it’s not open still. Might as well take another year or two
before it happens…
What are you saving anyway by not providing it, space on the CD image?
At least put it on your homepage along with other ‘unsupported’ stuff.
Actually, Good Point!
I just heard that one of my favorite tools might not work and decided to get
involved. But you’re right. I don’t think I’ll ever write a routine where
this will be an issue.
Colin Burgess <cburgess@qnx.com> wrote in message
news:95prk2$t59$1@nntp.qnx.com…
Bill at Sierra Design <> BC@sierradesign.com> > wrote:
Hi Colin,
I agree. Those of us that know how to use exceptions, NEED EXCEPTIONS.
And
if that means that the libraries must be compiled with -fexceptions then
we
NEED -fexceptions. It’s not a maybe.
The only case where C++ users lose without having the exceptions versions
of C libraries is if they throw an exception from a callback function
that was called from non-exception code. This is a very rare case, and
I don’t think it justifies adding 10-15% more data per process for this
case.
–
cburgess@qnx.com
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:95prk2$t59$1@nntp.qnx.com…
Bill at Sierra Design <> BC@sierradesign.com> > wrote:
Hi Colin,
I agree. Those of us that know how to use exceptions, NEED EXCEPTIONS.
And
if that means that the libraries must be compiled with -fexceptions then
we
NEED -fexceptions. It’s not a maybe.
The only case where C++ users lose without having the exceptions versions
of C libraries is if they throw an exception from a callback function
that was called from non-exception code. This is a very rare case, and
I don’t think it justifies adding 10-15% more data per process for this
case.
Hmmm, correct me if I’m wrong, but let’s say I wanted to write a resource
manager class (a wrapper for the resmgr lib). Is the resmgr lib
non-exception code ? Doesn’t the resmgr lib make extensive use of callbacks
? If I was writing a resmgr class, wouldn’t there be a very high
probability that I would throw an exception from inside a callback through
non-exception code (unless of course the resmgr lib is available in an
exception enabled version) ?
I disagree with Bill’s extreme position (as stated above), and as I said,
the availability of source is fine; but quite frankly, I can see myself
writing a resmgr class pretty soon (in fact, I had already put this on my
project queue).
Rennie
John Doe <john@csical.com> wrote:
…
The only case where C++ users lose without having the exceptions versions
of C libraries is if they throw an exception from a callback function
that was called from non-exception code. This is a very rare case, and
I don’t think it justifies adding 10-15% more data per process for this
case.
Hmmm, correct me if I’m wrong, but let’s say I wanted to write a resource
manager class (a wrapper for the resmgr lib). Is the resmgr lib
non-exception code ? Doesn’t the resmgr lib make extensive use of callbacks
? If I was writing a resmgr class, wouldn’t there be a very high
probability that I would throw an exception from inside a callback through
non-exception code (unless of course the resmgr lib is available in an
exception enabled version) ?
I see your point, Rennie, but in this case isn’t throwing an exception
within such an elaborate framework just asking for trouble? I’m sure
that the resmgr framework wasn’t constructed with exceptions in mind - it
expects these callouts to return, and indicate errors appropriately. Having
the trace of execution jump suddenly out of a callout would break the system.
I disagree with Bill’s extreme position (as stated above), and as I said,
the availability of source is fine; but quite frankly, I can see myself
writing a resmgr class pretty soon (in fact, I had already put this on my
project queue).
Sure, by all means. But I think that you’ll have to either completely
redo the framework in C++, or else catch all exceptions before returning
control to the framework, and then ‘translate’ them into the appropriate
error code.
–
cburgess@qnx.com
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:95qi6i$b9p$1@nntp.qnx.com…
John Doe <> john@csical.com> > wrote:
…
I see your point, Rennie, but in this case isn’t throwing an exception
within such an elaborate framework just asking for trouble? I’m sure
that the resmgr framework wasn’t constructed with exceptions in mind - it
expects these callouts to return, and indicate errors appropriately.
Having
the trace of execution jump suddenly out of a callout would break the
system.
I agree that if your writing a C++ class that is a wrapper for something
like the resmgr lib, ones use of exceptions that pass through the resmgr lib
is limited (to catching fatal exceptions). This is, however, still useful.
Sure, by all means. But I think that you’ll have to either completely
redo the framework in C++, or else catch all exceptions before returning
control to the framework, and then ‘translate’ them into the appropriate
error code.
Actually, this makes sense (to me anyway); most of the non-fatal exceptions
should be able to be “corrected” within the callout (i.e. either resolved
one way or another, or translated to an error code), only the fatal
exceptions need to propagate through the resmgr lib to the super class (of
course, if the exception is fatal, it doesn’t really matter that the resmgr
lib
is broken by this action). I would think that even if the whole shabang
were written in C++ that this would be a reasonable exception
architecture (i.e. handling the resolvable issues in the derived behaviour ,
and
handling all the unresolvable issues in the base class). As an O-O language
C++ does not have many endearing attributes (IMO), but the ability to
integrate well with C is most definately one of them.
Rennie
btw: I thought that I had posted this message this morning, but I discovered
that my 3 year old had woken up after we went to bed sometime last
night, and changed the date on my wifes computer into the future, and
inn.qnx.com had politely refused to post, due to the fact that my
post
was “in the future” ;-(
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:95qi6i$b9p$1@nntp.qnx.com…
John Doe <> john@csical.com> > wrote:
…
I see your point, Rennie, but in this case isn’t throwing an exception
within such an elaborate framework just asking for trouble? I’m sure
that the resmgr framework wasn’t constructed with exceptions in mind - it
expects these callouts to return, and indicate errors appropriately.
Having
the trace of execution jump suddenly out of a callout would break the
system.
I agree that if your writing a C++ class that is a wrapper for something
like the resmgr lib, ones use of exceptions that pass through the resmgr lib
is limited (to catching fatal errors). This is, however, still useful.
Sure, by all means. But I think that you’ll have to either completely
redo the framework in C++, or else catch all exceptions before returning
control to the framework, and then ‘translate’ them into the appropriate
error code.
Actually, this makes sense (to me anyway); most of the non-fatal exceptions
should be able to be “corrected” within the callout (i.e. either resolved
one way or another, or translated to an error code), only the fatal
exceptions need to propagate through the resmgr lib to the encapsulating
class (of course, if the exception is fatal, it doesn’t really matter that
the resmgr
lib is broken by this action). I would think that even if the whole shabang
were written in C++ that this would be a reasonable exception architecture
(i.e. handling the resolvable issues in the derived behaviour , and handling
all
the unresolvable issues in the base class). As an O-O language C++ does
not have many endearing attributes, but the ability to integrate well with C
is
most definately one of them.
Rennie