By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,928 Members | 1,173 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,928 IT Pros & Developers. It's quick & easy.

Overflow exception on a return?

P: n/a
I have a class with the following public function:

float FuncClass::GetResult() {
try {
return(Result);
} catch (...) {
WriteString("FuncClass::GetResult ERROR: Exception encountered");
return(0);
}
}

Result is a private variable of type float. I am repeatedly seeing the
catch portion being executed from the above code, and my Borland debugger is
telling me that it is an EOverflow exception.

How is it possible that such an exception is triggered by a return
statement. It would seem logical that if an overflow situation occurrs, it
would happen when I am assigning (an addition) to the Result variable, but
not when I am returning the Result variable. How is this possible?
Jul 19 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Victor Hannak wrote:
I have a class with the following public function:

float FuncClass::GetResult() {
try {
return(Result);
} catch (...) {
WriteString("FuncClass::GetResult ERROR: Exception encountered");
return(0);
}
}

Result is a private variable of type float. I am repeatedly seeing
the catch portion being executed from the above code, and my Borland
debugger is telling me that it is an EOverflow exception.

How is it possible that such an exception is triggered by a return
statement. It would seem logical that if an overflow situation
occurrs, it would happen when I am assigning (an addition) to the
Result variable, but not when I am returning the Result variable.
How is this possible?


First of all I guess this is not a standard mandated behavior. The second
(guess, since you did not post the code, only a fragment) is that you return
a double as a flot - and it just does not fit.

Attila
Jul 19 '05 #2

P: n/a
Actually, Result _is_ of type float. That was the first thing I thought of.

I'm not sure how much more code I need to post, after all, the segment I
included is the portion that's causing the exception. I would think that no
matter what my program does (to the result variable) before this code is
called should be irrelevant.

Anyone have any suggestion on what I could do to try to figure out what's
going on?

Vic
First of all I guess this is not a standard mandated behavior. The second
(guess, since you did not post the code, only a fragment) is that you return a double as a flot - and it just does not fit.

Jul 19 '05 #3

P: n/a
Victor,

My answer may seem harsh to you, but please bear in mind that my aim is
to provide you with some guidelines for effectively getting meaningful
help from this group.

Top-posting fixed. Please don't top-post on usenet. Look at this:
http://www.parashift.com/c++-faq-lit...t.html#faq-5.4

Victor Hannak wrote:
Atilla wrote: <snip>
since you did not post the code, only a fragment)<snip>

I'm not sure how much more code I need to post, after all, the segment I
included is the portion that's causing the exception.


What ever you post, it should be compilable. That means that we should
be able to cut and paste exactly what you've posted and compile it and
see the same problem you're seeing. This will require some effort on
your part, as you will have to isolate the problem. The upside is that
this is often enough to figure out what the problem is without waiting
for a response on usenet.
I would think that no
matter what my program does (to the result variable) before this code is
called should be irrelevant.
<snip>


This is almost certainly not true. I've added a minimal amount of code
required to turn your fragment into a compilable unit (see below), and
no exception is thrown. That seems to indicate that the problem is not
in the fragment you posted.

-----------------
#include <iostream>

class FuncClass
{
public:
FuncClass(float r) : Result(r) {}

float GetResult();

private:
void WriteString(const char* s)
{
std::cerr << s << '\n';
}

float Result;
};
float FuncClass::GetResult() {
try {
return(Result);
} catch (...) {
WriteString("FuncClass::GetResult ERROR: Exception encountered");
return(0);
}
}

int
main()
{
FuncClass fc(1.0);
std::cout << fc.GetResult() << '\n';

return 0;
}
-----------------

- Adam

Jul 19 '05 #4

P: n/a
I have been unable to isolate _or_ reproduce the problem in a simple
testcase. That is why I posted to the group in the first place... I was
hoping for a response from someone saying something like: "I had that same
problem before when I didn't initialize the class public variable I was
returning".
What ever you post, it should be compilable. That means that we should
be able to cut and paste exactly what you've posted and compile it and
see the same problem you're seeing. This will require some effort on
your part, as you will have to isolate the problem. The upside is that
this is often enough to figure out what the problem is without waiting
for a response on usenet.


I think you've missed my point here. I completely agree that the problem is
not with the posted fragment (otherwise, I could generate a testcase). The
question is what could I possibly be doing wrong prior to the return that
would cause an exception when the return is called, while not causing an
exception prior to the return.
I would think that no
matter what my program does (to the result variable) before this code is
called should be irrelevant.
<snip>


This is almost certainly not true. I've added a minimal amount of code
required to turn your fragment into a compilable unit (see below), and
no exception is thrown. That seems to indicate that the problem is not
in the fragment you posted.

Jul 19 '05 #5

P: n/a
Top posting fixed...my apologies...

"Victor Hannak" <victor.hannak@no****@rochester.rr.com> wrote in message
news:p3*****************@twister.nyroc.rr.com...
What ever you post, it should be compilable. That means that we should
be able to cut and paste exactly what you've posted and compile it and
see the same problem you're seeing. This will require some effort on
your part, as you will have to isolate the problem. The upside is that
this is often enough to figure out what the problem is without waiting
for a response on usenet.
I have been unable to isolate _or_ reproduce the problem in a simple
testcase. That is why I posted to the group in the first place... I was
hoping for a response from someone saying something like: "I had that same
problem before when I didn't initialize the class public variable I was
returning".
I would think that no
matter what my program does (to the result variable) before this code is called should be irrelevant.
<snip>


This is almost certainly not true. I've added a minimal amount of code
required to turn your fragment into a compilable unit (see below), and
no exception is thrown. That seems to indicate that the problem is not
in the fragment you posted.


I think you've missed my point here. I completely agree that the problem

is not with the posted fragment (otherwise, I could generate a testcase). The question is what could I possibly be doing wrong prior to the return that
would cause an exception when the return is called, while not causing an
exception prior to the return.

Jul 19 '05 #6

P: n/a
Victor Hannak wrote:
Top posting fixed...my apologies...


Victor, I have only few suggestions to you (since I have never used a system
where such overflow exception was present).

RTFM. Take your manual and read when does such overflow exception occur.
This - even if it will not give you the ahaaaa effect and make you
immediately find the problem - will at least help you on knowing what are
you looking for.

If the previous step did not help to find the error fire up the debugger and
stop your code right before it would run that very return statement.
Examine the programs state and look for such things, which can cause the
overflow (as you have learnt about all of them by reading the manual).

As these overflow (as far as I know) are not standardized for C++ (I might
be very wrong about it) you will need to see your docs (compiler or CPU) to
figure out what can cause such an overflow.

As a last guess it might also be possible that it is not the return
statement itself, but you are trying to put the returned number into a type
(variable?) where it does not fit. But of course it is just a guess, since
I do not know when can such exception occur. But (for example) if the
return value gets converted to int (or something else which might overflow)
you will probably see this as if the return statement itself did throw...

--
WW aka Attila
Jul 19 '05 #7

P: n/a
Victor Hannak wrote:
Top posting fixed...my apologies...


Um... You are top-posting to tell us that you won't top-post anymore?

....
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.