Discussion:
Catching floating exceptions
(too old to reply)
u***@sta.samsung.com
2007-06-01 01:41:52 UTC
Permalink
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
2007-06-01 01:48:05 UTC
Permalink
Post by u***@sta.samsung.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?
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.
James Kanze
2007-06-01 13:45:29 UTC
Permalink
Post by Ian Collins
Post by u***@sta.samsung.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?
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:***@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
terminator
2007-06-02 10:47:16 UTC
Permalink
Post by James Kanze
Post by Ian Collins
Post by u***@sta.samsung.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?
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.
--
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
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
2007-06-02 11:20:41 UTC
Permalink
Post by terminator
Post by James Kanze
Post by Ian Collins
Post by u***@sta.samsung.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?
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.
--
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
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.
Post by terminator
currently ,static variable constructors also may throw exceptions that
I am not sure could be catched.
Caught by what?
--
Ian Collins.
terminator
2007-06-02 22:11:13 UTC
Permalink
Post by Ian Collins
Signals are not "old style exceptions". They are asynchronous events.
yes they are traps/interupts(which one?)
Post by Ian Collins
Post by terminator
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
2007-06-02 22:36:28 UTC
Permalink
Post by terminator
Post by Ian Collins
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.
Post by terminator
Post by Ian Collins
Post by terminator
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
2007-06-03 17:35:10 UTC
Permalink
Post by Ian Collins
Post by terminator
Post by Ian Collins
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.)
Post by Ian Collins
Post by terminator
Post by Ian Collins
Post by terminator
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: ***@gmail.com
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
Ian Collins
2007-06-03 22:06:38 UTC
Permalink
Post by James Kanze
Post by Ian Collins
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
2007-06-04 02:52:18 UTC
Permalink
Post by Ian Collins
Post by James Kanze
Post by Ian Collins
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
2007-06-04 04:31:14 UTC
Permalink
Post by Default User
Post by Ian Collins
Post by James Kanze
Post by Ian Collins
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
2007-06-04 04:38:18 UTC
Permalink
Post by Default User
Post by Ian Collins
Post by James Kanze
Post by Ian Collins
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.
Post by Default User
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
2007-06-04 07:22:34 UTC
Permalink
Post by Default User
Post by Rolf Magnus
Post by Default User
Post by Ian Collins
Post by James Kanze
Post by Ian Collins
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:***@gmail.com
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
Ian Collins
2007-06-04 07:35:36 UTC
Permalink
Post by James Kanze
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
2007-06-04 13:40:48 UTC
Permalink
Post by Ian Collins
Post by James Kanze
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:***@gmail.com
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
Default User
2007-06-04 16:46:58 UTC
Permalink
Post by James Kanze
Post by Ian Collins
Post by James Kanze
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.
Post by James Kanze
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.
Post by James Kanze
--
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
Brian
Default User
2007-06-04 16:46:17 UTC
Permalink
Post by James Kanze
Post by Default User
Post by Rolf Magnus
Post by Default User
Post by Ian Collins
Post by James Kanze
Post by Ian Collins
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.
Post by James Kanze
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.
Post by James Kanze
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
Generic Usenet Account
2007-06-06 15:20:26 UTC
Permalink
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.
Generic Usenet Account
2007-06-06 15:21:42 UTC
Permalink
Post by 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.
Here it goes ....

/////////////////// Header File ///////////
#ifndef _FPEHANDLER_H_
#define _FPEHANDLER_H_

#include <pthread.h>
#include <setjmp.h>
#include <stdexcept>
#include <stack>

using namespace std;

/////////////////////////////////////////////////////////////////////
//
// Floating Point Error Handler class
//
/////////////////////////////////////////////////////////////////////
class FPEHandler
{
public:

virtual ~FPEHandler();
static FPEHandler& instance();

void provideLastBuf(jmp_buf& jb) throw (runtime_error);

jmp_buf* openFPOLocation();

bool closeFPOLocation(const jmp_buf* jbPtr);

jmp_buf* lastFPOLocation();

protected:
FPEHandler();

static FPEHandler* _instance;
pthread_mutex_t _mutex;

stack<jmp_buf*> _fpLocLIFO; // floating point location
LIFO
};


#endif //_FPEHANDLER_H_






////////////// Source File ////////////////
#include "FPEHandler.h"

#include <iostream>
#include <sstream>
#include <sys/time.h>

using namespace std;

//
// ---------------Defining static variables---------------------------
//
FPEHandler* FPEHandler::_instance = new FPEHandler();

/////////////////////////////////////////////////////////////////////////
FPEHandler::FPEHandler()
{
#ifdef TRACE
cout << "Creating FPEHandler object" << endl;
#endif

// Initialize the mutex attribute
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
attr.__mutexkind = PTHREAD_MUTEX_RECURSIVE_NP;

// Initialize the mutex
pthread_mutex_init(&_mutex,&attr);

}

/////////////////////////////////////////////////////////////////////////
FPEHandler::~FPEHandler()
{
#ifdef TRACE
cout << "Deleting FPEHandler object" << endl;
#endif


// Lock the mutex
if(pthread_mutex_lock(&_mutex))
{
throw runtime_error(strerror(errno));
}


while(!_fpLocLIFO.empty()) _fpLocLIFO.pop();

// Destroy the mutex
if(pthread_mutex_destroy(&_mutex))
{
throw runtime_error(strerror(errno));
}
}


/////////////////////////////////////////////////////////////////////////
FPEHandler&
FPEHandler::instance()
{
if(_instance == NULL)
_instance = new FPEHandler;
return *_instance;
}


/////////////////////////////////////////////////////////////////////////
jmp_buf*
FPEHandler::openFPOLocation()
{
jmp_buf* jbPtr = NULL;

// Lock the mutex
if(pthread_mutex_lock(&_mutex))
{
cerr << "File: " << __FILE__ << ", Line: " << __LINE__ << ",
Function: "
<< __func__ << "()\n";
cerr << strerror(errno) << endl;
return jbPtr;
}

jbPtr = (jmp_buf *) malloc(sizeof(jmp_buf));

_fpLocLIFO.push(jbPtr);
#ifdef DEBUG
cout << "Currently " << _fpLocLIFO.size() << " entries in the LIFO
\n";
#endif // DEBUG

// Unlock the mutex
if(pthread_mutex_unlock(&_mutex))
{
free (jbPtr);
jbPtr = NULL;
cerr << "File: " << __FILE__ << ", Line: " << __LINE__ << ",
Function: "
<< __func__ << "()\n";
cerr << strerror(errno) << endl;
}

return jbPtr;
}


/////////////////////////////////////////////////////////////////////////
bool
FPEHandler::closeFPOLocation(const jmp_buf*)
{
bool retVal = false;

// Currently because of the stack implementation, the input
parameter
// is not used. At some future point we may consider getting rid of
this
// parameter altogether (although then the API will no longer follow
the
// STDIO File I/O API)

// Lock the mutex
if(pthread_mutex_lock(&_mutex))
{
cerr << "File: " << __FILE__ << ", Line: " << __LINE__ << ",
Function: "
<< __func__ << "()\n";
cerr << strerror(errno) << endl;
return retVal;
}

if(!_fpLocLIFO.empty())
{
retVal = true;
_fpLocLIFO.pop();
#ifdef DEBUG
cout << _fpLocLIFO.size() << " entries left in the LIFO\n";
#endif // DEBUG
}

// Unlock the mutex
if(pthread_mutex_unlock(&_mutex))
{
retVal = false;
cerr << "File: " << __FILE__ << ", Line: " << __LINE__ << ",
Function: "
<< __func__ << "()\n";
cerr << strerror(errno) << endl;
}
return retVal;
}


/////////////////////////////////////////////////////////////////////////
jmp_buf*
FPEHandler::lastFPOLocation()
{
jmp_buf *jbPtr = NULL;

// Lock the mutex
if(pthread_mutex_lock(&_mutex))
{
cerr << "File: " << __FILE__ << ", Line: " << __LINE__ << ",
Function: "
<< __func__ << "()\n";
cerr << strerror(errno) << endl;
return jbPtr;
}

if(!_fpLocLIFO.empty())
{
jbPtr = _fpLocLIFO.top();
}

// Unlock the mutex
if(pthread_mutex_unlock(&_mutex))
{
jbPtr = NULL;
cerr << "File: " << __FILE__ << ", Line: " << __LINE__ << ",
Function: "
<< __func__ << "()\n";
cerr << strerror(errno) << endl;
}

return jbPtr;
}



/////////// Driver File /////////////////
#include <signal.h>
#include <stdexcept>
#include "FPEHandler.h"

#include <iostream>

using namespace std;


/* Traditional UNIX Signal Handling */
typedef void sigfunc_trad(int);

sigfunc_trad * sig_install_trad(int, sigfunc_trad*);




/* Real-time UNIX Signal Handling (POSIX) */
typedef void sigfunc_rt(int, siginfo_t*, void*);

sigfunc_rt * sig_install_rt(int, sigfunc_rt*);
sigfunc_rt * sig_install(int, sigfunc_rt*);


/////////////////////////////////////////////////////////////////////////
//
// Traditional Signal Installer
//
/////////////////////////////////////////////////////////////////////////
sigfunc_trad *
sig_install_trad(int signo, sigfunc_trad *func)
{
sigfunc_trad *sigfunc = SIG_IGN;
if(signal(signo, func) != SIG_IGN)
sigfunc = signal(signo, func);
return sigfunc;
}




/////////////////////////////////////////////////////////////////////////
//
// Real Time Signal Installer (POSIX)
//
/////////////////////////////////////////////////////////////////////////
sigfunc_rt *
sig_install_rt(int signo, sigfunc_rt *func)
{
sigfunc_rt *sigfunc;

struct sigaction act, oact;

act.sa_sigaction = func; /* must store function addr here */
sigemptyset(&act.sa_mask);
act.sa_flags = SA_SIGINFO; /* must specify this for realtime */


if (sigaction(signo, &act, &oact) < 0)
{
sigfunc = (sigfunc_rt *) SIG_ERR;
#ifdef DEBUG
cerr << "sig_install error\n";
#endif // DEBUG
}
else
sigfunc = oact.sa_sigaction;

return sigfunc;
}


/////////////////////////////////////////////////////////////////////////
//
// Real Time Signal Installer (POSIX)
//
/////////////////////////////////////////////////////////////////////////
sigfunc_rt *
sig_install(int signo, sigfunc_rt *func)
{
return sig_install_rt(signo, func);
}



int nan_x = 1, nan_y = 1, minusinf_x = 1, minusinf_y = 1, plusinf_x =
1, plusinf_y = 1;


/////////////////////////////////////////////////////////////////////
//
/////////////////////////////////////////////////////////////////////
void
sig_handler(int signo)
{
signal(signo, sig_handler);

#ifdef DEBUG
cout << "Trapping signal number " << signo << endl;
#endif // DEBUG

switch(signo)
{
case SIGFPE:
{
jmp_buf *jbPtr = FPEHandler::instance().lastFPOLocation();
if(jbPtr)
longjmp(*jbPtr, 1);
else
{
cerr << "Cannot determine jump location ---- aborting \n\n
\n";
abort();
}
}
break;

default:
break;
}

}


/////////////////////////////////////////////////////////////////////
//
/////////////////////////////////////////////////////////////////////
float
generate_plusInfinity(int x, int y) throw (runtime_error)
{
float retVal = 0;

jmp_buf *jbPtr = NULL;

if((jbPtr = FPEHandler::instance().openFPOLocation()) != NULL)
{
if(setjmp(*jbPtr) == 0)
{
retVal = (1)/(x-y);
FPEHandler::instance().closeFPOLocation(jbPtr);
}
else
throw runtime_error("Floating point error");
}
return retVal;
}



/////////////////////////////////////////////////////////////////////
//
/////////////////////////////////////////////////////////////////////
float
generate_minusInfinity(int x, int y) throw (runtime_error)
{
float retVal = 0;

jmp_buf *jbPtr = NULL;

if((jbPtr = FPEHandler::instance().openFPOLocation()) != NULL)
{
if(setjmp(*jbPtr) == 0)
{
retVal = (-1)/(x-y) + generate_plusInfinity(plusinf_x,
plusinf_y);
FPEHandler::instance().closeFPOLocation(jbPtr);
}
else
throw runtime_error("Floating point error");
}
return retVal;
}




/////////////////////////////////////////////////////////////////////
//
/////////////////////////////////////////////////////////////////////
void
generate_nan(int x, int y) throw (runtime_error)
{
float nan = 0;

x++; y+=2;

jmp_buf *jbPtr = NULL;

if((jbPtr = FPEHandler::instance().openFPOLocation()) != NULL)
{
if(setjmp(*jbPtr) == 0)
{
nan = generate_minusInfinity(minusinf_x, minusinf_y) + (x-2)/
(y-3);
FPEHandler::instance().closeFPOLocation(jbPtr);
}
else
throw runtime_error("Floating point error");
}
}




/////////////////////////////////////////////////////////////////////
//
/////////////////////////////////////////////////////////////////////
main()
{
sig_install_trad(SIGFPE, sig_handler);

try
{
generate_nan(nan_x, nan_y);
}
catch (const exception& xcptn)
{
cerr << "Exception: " << xcptn.what() << " detected at " <<
__FILE__ << ", line " << __LINE__ << endl;

}

cout << "\n\n\n";

for(int i = -2; i < 3; i++)
{
try
{
generate_nan(i, i);
}
catch (const exception& xcptn)
{
cerr << "Exception: " << xcptn.what() << " detected at " <<
__FILE__ << ", line " << __LINE__ << endl;

}
cout << "In for loop with loop index " << i << "\n\n\n";
}
cout << "Goodbye\n";
}

Pete Becker
2007-06-02 12:05:47 UTC
Permalink
Post by terminator
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)
Jim Langston
2007-06-01 02:29:50 UTC
Permalink
Post by u***@sta.samsung.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
2007-06-01 04:23:52 UTC
Permalink
Post by u***@sta.samsung.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?
The first thing you should do is decide whether you are programming in C++
or in D.
terminator
2007-06-01 05:01:41 UTC
Permalink
Post by u***@sta.samsung.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?
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 .
Loading...