Jump to content
  • Advertisement
Sign in to follow this  
irreversible

automated exception handling for common data types

This topic is 4337 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I can't seem to find a definitve answer as to whether overloading operators (specifically devision) for common data types (such as ints and floats) is possible or whether it is feasible (performance wise). I'd like to extend automated excpetion handling to third party code, which would include internal exception handling for common faults, such as division by zero without having to write nasty functions to do the job. [Edited by - irreversible on July 8, 2006 2:58:40 PM]

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Quote:
Original post by irreversible
I can't seem to find a definitve answer as to whether overloading operators (specifically devision) for common data types (such as ints and floats) is possible or whether it is feasible (performance wise).


Sounds like a generally bad idea.

Quote:

I'd like to extend automated excpetion handling to third party code, which would include internal exception handling for common faults, such as division by zero without having to write nasty functions to do the job.


I'm not sure what you're trying to do - but adding your own operator overloadings won't change anything in any third party library you might already have.

Share this post


Link to post
Share on other sites
If you're on Windows, you can use Structured Exception Handling to trap div-0 and other hardware-level exceptions easily, without screwing around with operator overloading.

In general, I'd say that overloading operators for intrinsics is going to be a bad idea for performance in general. If you're having that much trouble with invalid data causing screwy mathematical situations (i.e. if div-0 is actually "common" as you say) then you've likely got some design issues.

Share this post


Link to post
Share on other sites
Mmkay - I tried it with the simplest possible test:


__try
{
int a = 0;
int b = 0;
a = a / b;
}
__except(GetExceptionCode() == STATUS_INTEGER_DIVIDE_BY_ZERO)
{
MessageBox(0, 0, "Error: Divide By Zero!", 0);
}




And it doesn't report anything. Note that I've set the EHa compiler flag.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
So what do we learn from this? We learn that not only is it a bad idea, it doesn't even work.

Share this post


Link to post
Share on other sites
Quote:
Original post by irreversible
Mmkay - I tried it with the simplest possible test:

*** Source Snippet Removed ***

And it doesn't report anything. Note that I've set the EHa compiler flag.



... That would be because your code is nonsensical. Read up a bit on SEH and its syntax. Your __except block is the culprit.

Share this post


Link to post
Share on other sites

__except(
rec = *(GetExceptionInformation())->ExceptionRecord,
con = *(GetExceptionInformation())->ContextRecord,
EXCEPTION_EXECUTE_HANDLER)


Does that make more sense?

It's trapping access violation exceptions, but not division by zero. In fact, there's no response from the system to division by zero (last I remember, the process was supposed to be stopped by the OS and an "undhandled exception" message displayed). I'm not sure why...

Share this post


Link to post
Share on other sites
That should work better, yes.

Any chance your div-0 is getting optimized away? Try reading a number from the console and then dividing that by 0.

Share this post


Link to post
Share on other sites
Quote:
Original post by ApochPiQ
That should work better, yes.

Any chance your div-0 is getting optimized away? Try reading a number from the console and then dividing that by 0.



Well, if the compiler can optimize away this, then I'm impressed :)

int d = rand() % 2;
if(d != 1) d = 1;
int a = d - 1;
int c = d / a; //should be 1 / 0



It won't react to stack overflow:

int overflow[100000000];



... and out of array bounds:

char beta[10];
beta[11] = 2;



... exceptions either.





I don't so much care for the stack overflow, but EXCEPTION_ARRAY_BOUNDS_EXCEEDED is just plain useful sometimes as it's pretty much the only thing you can't catch easily when debugging.

Share this post


Link to post
Share on other sites
The first two throw an exception quite reliably for me. Maybe you should post your entire test code so we can see if there's something else involved. (It might be that your CPU doesn't support hardware div-0 exceptions, or they're disabled for some reason, but that seems unlikely.)


The third will not throw an exception; detecting that is not so easy. (Think about it - if an exception was thrown every time you access an array out of bounds, why doesn't it reliably crash programs?) EXCEPTION_ARRAY_BOUNDS_EXCEEDED requires that the hardware supports bounds checking and some other housekeeping code has to be in place. In general, it's safe to say you'll never see this exception - and even if you do, never count on it occurring.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!