Catching floating exceptions

[usenet]

I am unable to catch floating exceptions (e.g. divide by 0 or 0/0)
using the standard exceptions defined in stdexcept. What is the
recommended way to catch such exceptions?

Thanks,
Song

[Ian Collins]

us****@sta.samsung.com wrote:

I am unable to catch floating exceptions (e.g. divide by 0 or 0/0)
using the standard exceptions defined in stdexcept. What is the
recommended way to catch such exceptions?

You can't. At least not in standard C++, there might be platform
specific extensions, but hardware generated traps are not the same as
C++ language exceptions.

--
Ian Collins.

[Jim Langston]

<us****@sta.samsung.comwrote in message
news:11**********************@p77g2000hsh.googlegr oups.com...

>I am unable to catch floating exceptions (e.g. divide by 0 or 0/0)
using the standard exceptions defined in stdexcept. What is the
recommended way to catch such exceptions?

Is the problem that no exception is thrown? An integer divide by zero will
throw a system error, a floating point divide by error should return
infinity or negative infinity. Consider the following program I just threw
together. There is probably a better way, but I'm just not sure what it is.

#include <iostream>
#include <cfloat>

int main()
{

float Zero = 0.0f;
float Inf = 5.0f / Zero;
float NegInf = -5.0f / Zero;

float x = -5.0f;
float y = 0.0f;
float z = x/y;

std::cout << z << "\n";
if ( z == Inf || z == -Inf )
std::cout << "Division By Zero (infinity) " << "\n";

return 0;
}

[Rolf Magnus]

us****@sta.samsung.com wrote:

I am unable to catch floating exceptions (e.g. divide by 0 or 0/0)
using the standard exceptions defined in stdexcept. What is the
recommended way to catch such exceptions?

The first thing you should do is decide whether you are programming in C++
or in D.

[terminator]

On Jun 1, 5:41 am, [e-mail] wrote:

I am unable to catch floating exceptions (e.g. divide by 0 or 0/0)
using the standard exceptions defined in stdexcept. What is the
recommended way to catch such exceptions?

Thanks,
Song

using C (not C++) libraries you can do this via 'signals' and you need
use 'setjmp' and 'longjmp' functions which are not commonly used since
the new exception handling mechanism(try-catch-throw) has been
introduced. I am not certain on details but you need read
documentations on 'signal' mechanism .

[James Kanze]

On Jun 1, 3:48 am, Ian Collins <[e-mail]:

[e-mail] wrote:

I am unable to catch floating exceptions (e.g. divide by 0 or 0/0)
using the standard exceptions defined in stdexcept. What is the
recommended way to catch such exceptions?

You can't. At least not in standard C++, there might be platform
specific extensions, but hardware generated traps are not the same as
C++ language exceptions.

In general (on a machine with IEEE floating point), divide by 0
will not generate an exception. Nor a hardware trap, nor
anything else that will interrupt normal program flow. On most
systems, anything floating point error which will cause a
hardware trap will be mapped to SIGFPE, which you can trap, but
you can't throw an exception from a signal handler, so that may
not solve the problem either.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Rolf Magnus]

terminator wrote:

On Jun 1, 5:41 am, [e-mail] wrote:

>I am unable to catch floating exceptions (e.g. divide by 0 or 0/0)
using the standard exceptions defined in stdexcept. What is the
recommended way to catch such exceptions?

Thanks,
Song

using C (not C++) libraries you can do this via 'signals'

.... on some systems

and you need use 'setjmp' and 'longjmp' functions which are not commonly
used since the new exception handling mechanism(try-catch-throw) has been
introduced.

There are compilers that actually implement try/catch/throw by means of
setjmp and longjmp.

[terminator]

On Jun 1, 9:29 pm, Rolf Magnus <[e-mail]:

terminator wrote:

On Jun 1, 5:41 am, [e-mail] wrote:

I am unable to catch floating exceptions (e.g. divide by 0 or 0/0)
using the standard exceptions defined in stdexcept. What is the
recommended way to catch such exceptions?

Thanks,
Song

using C (not C++) libraries you can do this via 'signals'

... on some systems

and you need use 'setjmp' and 'longjmp' functions which are not commonly
used since the new exception handling mechanism(try-catch-throw) has been
introduced.

There are compilers that actually implement try/catch/throw by means of
setjmp and longjmp.

but I do not think it is possible to change the way try/catch/throw
without switching to another compiler

[terminator]

On Jun 2, 2:32 pm, terminator <[e-mail]:

>
but I do not think it is possible to change the way try/catch/throw
without switching to another compiler- Hide quoted text -

- Show quoted text -

Sorry.but I do not think it is possible to change the way try/catch/
throw behaves without switching to another compiler.

regards,
FM

[terminator]

On Jun 1, 5:45 pm, James Kanze <[e-mail]:

On Jun 1, 3:48 am, Ian Collins <[e-mail]:

[e-mail] wrote:

I am unable to catch floating exceptions (e.g. divide by 0 or 0/0)
using the standard exceptions defined in stdexcept. What is the
recommended way to catch such exceptions?

You can't. At least not in standard C++, there might be platform
specific extensions, but hardware generated traps are not the same as
C++ language exceptions.

In general (on a machine with IEEE floating point), divide by 0
will not generate an exception. Nor a hardware trap, nor
anything else that will interrupt normal program flow. On most
systems, anything floating point error which will cause a
hardware trap will be mapped to SIGFPE, which you can trap, but
you can't throw an exception from a signal handler, so that may
not solve the problem either.

--
James Kanze (GABI Software) email:[e-mail]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

wont it be good to provide a standard for libraries so as to declare
functions that convert old style exceptions to new ones?
currently ,static variable constructors also may throw exceptions that
I am not sure could be catched.

[Ian Collins]

terminator wrote:

On Jun 1, 5:45 pm, James Kanze <[e-mail]:

>On Jun 1, 3:48 am, Ian Collins <[e-mail]:

>>[e-mail] wrote:
I am unable to catch floating exceptions (e.g. divide by 0 or 0/0)
using the standard exceptions defined in stdexcept. What is the
recommended way to catch such exceptions?
You can't. At least not in standard C++, there might be platform
specific extensions, but hardware generated traps are not the same as
C++ language exceptions.

In general (on a machine with IEEE floating point), divide by 0
will not generate an exception. Nor a hardware trap, nor
anything else that will interrupt normal program flow. On most
systems, anything floating point error which will cause a
hardware trap will be mapped to SIGFPE, which you can trap, but
you can't throw an exception from a signal handler, so that may
not solve the problem either.

--
James Kanze (GABI Software) email:[e-mail]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

wont it be good to provide a standard for libraries so as to declare
functions that convert old style exceptions to new ones?

Signals are not "old style exceptions". They are asynchronous events.

currently ,static variable constructors also may throw exceptions that
I am not sure could be catched.

Caught by what?

--
Ian Collins.

[Pete Becker]

terminator wrote:

currently ,static variable constructors also may throw exceptions that
I am not sure could be catched.

They can, through a somewhat obscure mechanism called a "function try
block." Here's an example from the standard:

int f(int);
class C {
int i;
double d;
public:
C(int, double);
};

C::C(int ii, double id)
try
: i(f(ii)), d(id)
{
// constructor function body
}
catch (...)
{
// handles exceptions thrown from the ctor-initializer
// and from the constructor function body
}
--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

[terminator]

On Jun 2, 3:20 pm, Ian Collins <[e-mail]:

terminator wrote:
Signals are not "old style exceptions". They are asynchronous events.

yes they are traps/interupts(which one?)

currently ,static variable constructors also may throw exceptions that
I am not sure could be catched.

Caught by what?

--
Ian Collins.- Hide quoted text -

- Show quoted text -

Got it.on second thought it seems meaningless.

[Ian Collins]

terminator wrote:

On Jun 2, 3:20 pm, Ian Collins <[e-mail]:

>terminator wrote:
Signals are not "old style exceptions". They are asynchronous events.

yes they are traps/interupts(which one?)

I chose my words with care, they are events. How they are delivered is
a matter for the implementation.

>

>>currently ,static variable constructors also may throw exceptions that
I am not sure could be catched.

Caught by what?

--
Ian Collins.- Hide quoted text -

- Show quoted text -

Please don't quote signatures or all that google crap.

--
Ian Collins.

[James Kanze]

On Jun 3, 12:36 am, Ian Collins <[e-mail]:

terminator wrote:

On Jun 2, 3:20 pm, Ian Collins <[e-mail]:

terminator wrote:
Signals are not "old style exceptions". They are asynchronous events.

yes they are traps/interupts(which one?)

I chose my words with care, they are events. How they are delivered is
a matter for the implementation.

The important thing is that, regardless of what you call them,
they asynchronously interrupt the normal program flow, and that
there are only a very, very limited number of things you can do
in a signal handler. (Throwing an exception is not one of
them.)

>currently ,static variable constructors also may throw exceptions that
I am not sure could be catched.
Caught by what?

--
Ian Collins.- Hide quoted text -

- Show quoted text -

Please don't quote signatures or all that google crap.

Don't blame it on Google. I post through Google, and I don't
quote signatures. It's true that Google could strip the
signatures in the Post box, but it couldn't reasonably strip
anything else that is irrelevant---so you'd still have to trim
by hand.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ian Collins]

James Kanze wrote:

On Jun 3, 12:36 am, Ian Collins <[e-mail]:

>Please don't quote signatures or all that google crap.

Don't blame it on Google.

I wasn't, I was whinging about the - Hide quoted text - nonsense some
google uses leave in their replies.

--
Ian Collins.

[Default User]

Ian Collins wrote:

James Kanze wrote:

On Jun 3, 12:36 am, Ian Collins <[e-mail]:

Please don't quote signatures or all that google crap.

Don't blame it on Google.

I wasn't, I was whinging about the - Hide quoted text - nonsense some
google uses leave in their replies.

Which is also Google's fault.

Brian

[Rolf Magnus]

Default User wrote:

Ian Collins wrote:

>James Kanze wrote:

On Jun 3, 12:36 am, Ian Collins <[e-mail]:

Please don't quote signatures or all that google crap.

Don't blame it on Google.

I wasn't, I was whinging about the - Hide quoted text - nonsense some
google uses leave in their replies.

Which is also Google's fault.

Just like about all the spam you find in newsgroups. It's almost always
posted via Google groups, because their disposable accounts make abuse
reports worthless.

[Default User]

Rolf Magnus wrote:

Default User wrote:

Ian Collins wrote:

James Kanze wrote:
On Jun 3, 12:36 am, Ian Collins <[e-mail]:

Please don't quote signatures or all that google crap.

Don't blame it on Google.

I wasn't, I was whinging about the - Hide quoted text - nonsense

some >google uses leave in their replies.

Which is also Google's fault.

Just like about all the spam you find in newsgroups. It's almost
always posted via Google groups, because their disposable accounts
make abuse reports worthless.

That's true, but a different problem. There's no excuse whatsoever for
their news interface to work as poorly as it does. It's not like
they're exactly breaking new ground here.


Brian

[James Kanze]

On Jun 4, 6:38 am, "Default User" <[e-mail]:

Rolf Magnus wrote:

Default User wrote:

Ian Collins wrote:
>James Kanze wrote:
On Jun 3, 12:36 am, Ian Collins <[e-mail]:

>Please don't quote signatures or all that google crap.
Don't blame it on Google.
>I wasn't, I was whinging about the - Hide quoted text -
>nonsense some google uses leave in their replies.

Which is also Google's fault.

Just like about all the spam you find in newsgroups. It's almost
always posted via Google groups, because their disposable accounts
make abuse reports worthless.

That's true, but a different problem. There's no excuse
whatsoever for their news interface to work as poorly as it
does. It's not like they're exactly breaking new ground here.

They do have to make it work within a browser, which is not
designed for this sort of thing. The only real problem I have
with it is that it keeps crashing Firefox. This is obviously a
bug in Firefox (a program shouldn't crash, no matter what it is
sent), but the problem only occurs when I'll reading news
through Google (and then only when I'm running it with a remote
X server---for various reasons, the only way I can access news
at this site is through Google, using Firefox running on a Linux
box, addressing an X server on a Sparc under Solaris).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ian Collins]

James Kanze wrote:

>
They do have to make it work within a browser, which is not
designed for this sort of thing. The only real problem I have
with it is that it keeps crashing Firefox.

James, you forgot to mention the gratuitous munting of your signature!

--
Ian Collins.

[James Kanze]

On Jun 4, 9:35 am, Ian Collins <[e-mail]:

James Kanze wrote:

They do have to make it work within a browser, which is not
designed for this sort of thing. The only real problem I have
with it is that it keeps crashing Firefox.

James, you forgot to mention the gratuitous munting of your signature!

Is it still doing it? I think that that was due to the way I'd
integrated vim into Firefox, and (I hope) I've fixed it (on all
of the machines I use).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Default User]

James Kanze wrote:

On Jun 4, 6:38 am, "Default User" <[e-mail]:

Rolf Magnus wrote:

Default User wrote:
Ian Collins wrote:
James Kanze wrote:
On Jun 3, 12:36 am, Ian Collins <[e-mail]:

Please don't quote signatures or all that google crap.
Don't blame it on Google.
I wasn't, I was whinging about the - Hide quoted text -
nonsense some google uses leave in their replies.

Which is also Google's fault.

Just like about all the spam you find in newsgroups. It's almost
always posted via Google groups, because their disposable accounts
make abuse reports worthless.

That's true, but a different problem. There's no excuse
whatsoever for their news interface to work as poorly as it
does. It's not like they're exactly breaking new ground here.

They do have to make it work within a browser, which is not
designed for this sort of thing.

But that's nothing new. Several of the news services provide web
versions of news readers.

There's no excuse for that - Hide Quoted Text - business. Also no
excuse for not auto-trimming .sigs.

The only real problem I have
with it is that it keeps crashing Firefox.

I haven't had any problem with that, but I haven't used Google to post
much in a couple years.

This is obviously a
bug in Firefox (a program shouldn't crash, no matter what it is
sent), but the problem only occurs when I'll reading news
through Google (and then only when I'm running it with a remote
X server---for various reasons, the only way I can access news
at this site is through Google, using Firefox running on a Linux
box, addressing an X server on a Sparc under Solaris).

Oh.


Brian

[Default User]

James Kanze wrote:

On Jun 4, 9:35 am, Ian Collins <[e-mail]:

James Kanze wrote:

They do have to make it work within a browser, which is not
designed for this sort of thing. The only real problem I have
with it is that it keeps crashing Firefox.

James, you forgot to mention the gratuitous munting of your
signature!

Is it still doing it?

Yep.

I think that that was due to the way I'd
integrated vim into Firefox, and (I hope) I've fixed it (on all
of the machines I use).

Nope.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, [phone]

Brian

[Generic Usenet Account]

Thanks to all of you who proposed using setjmp and longjmp, in
conjunction with SIGFPE for handling floating exceptions. It was a
little more involved than I thought due to getting into an infinite
loop, with the signal handler being called endlessly called once the
SIG_FPE exception occurs. I have posted my implementation to
comp.sources.d.

Unfortunately this solution is not fully platform neutral since it
relies on signals.

I am really waiting to see the day when the C++ standard adopts a
consistent way for handling floating point exceptions.