how to catch the Arithmetic exception?

[Gary.Hu]

I was trying to catch the Arithmetic exception, unsuccessfully.
try{
int a = 0, b = 9;
b = b / a;
}catch(...){
cout << "arithmetic exception was catched!" << endl;
}

After ran the program, it quitted with core dumped.
%test
Arithmetic exception (core dumped)

who can tell me an appropriate approach?

[Jacques Labuschagne]

Gary.Hu wrote:

I was trying to catch the Arithmetic exception, unsuccessfully.
try{
int a = 0, b = 9;
b = b / a;
}catch(...){
cout << "arithmetic exception was catched!" << endl;
}

After ran the program, it quitted with core dumped.
%test
Arithmetic exception (core dumped)

who can tell me an appropriate approach?

When all else fails, why not try
catch(std::exception& e){
std::cout << e.what() << std::endl;
}
It's probably an exception of type std::runtime_error.

--
Emacs is a nice OS, but I prefer UNIX.

[Peter van Merkerk]

"Jacques Labuschagne" <ja*****@clawshrimp.com> wrote in message
news:1168213.OcskaVrlgv@klesk...

Gary.Hu wrote:

I was trying to catch the Arithmetic exception, unsuccessfully.
try{
int a = 0, b = 9;
b = b / a;
}catch(...){
cout << "arithmetic exception was catched!" << endl;
}

After ran the program, it quitted with core dumped.
%test
Arithmetic exception (core dumped)

who can tell me an appropriate approach?

When all else fails, why not try
catch(std::exception& e){
std::cout << e.what() << std::endl;
}

Is there any reason why catch(...) wouldn't catch exceptions that are
catched by catch(std::exception& e)...?

"Arithmetic exception" is probably an OS or processor exception which is
not the same as a C++ exception, hence it can not be catched by a
try/catch block. If you ask me you need platform and/or compiler
specific constructs to handle "Arithmetic exceptions".

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl

[Jack Klein]

On Mon, 21 Jul 2003 14:45:28 -0700, "Gary.Hu" <hu****@metarnet.com>
wrote in comp.lang.c++:

I was trying to catch the Arithmetic exception, unsuccessfully.
try{
int a = 0, b = 9;
b = b / a;
}catch(...){
cout << "arithmetic exception was catched!" << endl;
}

After ran the program, it quitted with core dumped.
%test
Arithmetic exception (core dumped)

who can tell me an appropriate approach?

Arithmetic errors of this type are not C++ exceptions, they are
undefined behavior. Your compiler might provide a way to turn them
into C++ exceptions, but it is not required to.

There are no requirements or guarantees on what might happen when you
generate undefined behavior.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Chris \( Val \)]

"Gary.Hu" <hu****@metarnet.com> wrote in message news:bf***********@mail.cn99.com...
| I was trying to catch the Arithmetic exception, unsuccessfully.
| try{
| int a = 0, b = 9;
| b = b / a;
| }catch(...){
| cout << "arithmetic exception was catched!" << endl;
| }
|
| After ran the program, it quitted with core dumped.
| %test
| Arithmetic exception (core dumped)
|
| who can tell me an appropriate approach?

Others have already indicated why you cannot catch these kind
of errors with standard C++ exception handlers, but why not
make a simple check, and then throw one of the available
'standard' exceptions yourself ?.

For example:

int main()
{
try
{
int a = 0, b = 9;
if( a == 0 )
throw std::runtime_error( "Divide by zero encountered. " );

b /= a;
}
catch( const std::runtime_error& e )
{
cout << e.what() << endl;
}

return 0;
}

Personally, I think using exceptions here is a bit of an overkill
anyway. What's wrong with a simple conditional check ?, such as:

if( a == 0 )
cout << "Divide by zero encountered. " << endl;
else
b /= a;

If you can handle the error locally, then why not ?
Exceptions are often misused, and should be avoided
if you *really* don't need them.

Cheers.
Chris Val

[Jacques Labuschagne]

Peter van Merkerk wrote:

When all else fails, why not try
catch(std::exception& e){
std::cout << e.what() << std::endl;
}
Is there any reason why catch(...) wouldn't catch exceptions that are
catched by catch(std::exception& e)...?

catch(...) catches everything; I'm not trying to say otherwise. Allow me to
rephrase my sentence:
"When all other attempts at deducing the actual type of an exception have
failed, why not try std::exception which is the base of all exceptions
generated by the standard library".

"Arithmetic exception" is probably an OS or processor exception which is
not the same as a C++ exception, hence it can not be catched by a
try/catch block. If you ask me you need platform and/or compiler
specific constructs to handle "Arithmetic exceptions".

Ah well... "If [...] the result is not mathematically defined or not in the
range of representable values for its type, the behaviour is undefined"
which, as we all know, means that all bets are off.

--
It isn't that unix isn't a user friendly operating system,
it's just choosy about which users it wants to be friends
with, and even the best of friends occasionally fight.

[Klaus Eichner]

"Jacques Labuschagne" <ja*****@clawshrimp.com> wrote in message
news:2360088.KJvXMtpkjA@klesk...

Peter van Merkerk wrote:

When all else fails, why not try
catch(std::exception& e){
std::cout << e.what() << std::endl;
}
Is there any reason why catch(...) wouldn't catch exceptions that are
catched by catch(std::exception& e)...?

catch(...) catches everything;

catch(...) catches all exceptions, but it does not catch a 'Divide by zero'
error. (unless, of course, the compiler generates code which throws
automatically on divide by zero, but this does not seem to be the case here)
I'm not trying to say otherwise. Allow me to
rephrase my sentence:
"When all other attempts at deducing the actual type of an exception have
failed, why not try std::exception which is the base of all exceptions
generated by the standard library".
....because std::exception is the base _only_ of exceptions generated by the
standard library (derived from std::exception) . There are, however, many,
many more exceptions which are not derived from std::excteption, but still
can be thrown, for example

class MyError{};
throw MyError();

The most general form is still catch(...).

"Arithmetic exception" is probably an OS or processor exception which is
not the same as a C++ exception, hence it can not be catched by a
try/catch block. If you ask me you need platform and/or compiler
specific constructs to handle "Arithmetic exceptions".
Ah well... "If [...] the result is not mathematically defined or not in

the range of representable values for its type, the behaviour is undefined"
which, as we all know, means that all bets are off.

--
It isn't that unix isn't a user friendly operating system,
it's just choosy about which users it wants to be friends
with, and even the best of friends occasionally fight.

[Chris \( Val \)]

"Klaus Eichner" <kl******@yahoo.com> wrote in message
news:3f**********************@news.free.fr...
| "Jacques Labuschagne" <ja*****@clawshrimp.com> wrote in message
| news:2360088.KJvXMtpkjA@klesk...
| > Peter van Merkerk wrote:

[snip]

| > I'm not trying to say otherwise. Allow me to
| > rephrase my sentence:
| > "When all other attempts at deducing the actual type of an exception have
| > failed, why not try std::exception which is the base of all exceptions
| > generated by the standard library".
|
| ...because std::exception is the base _only_ of exceptions generated by the
| standard library (derived from std::exception) . There are, however, many,
| many more exceptions which are not derived from std::excteption, but still
| can be thrown, for example
|
| class MyError{};
| throw MyError();
|
| The most general form is still catch(...).

Are you saying that 'catch( ... );' should be used ?

....rather than: catch( const MyError& e ); ?

AFAIU, the former should only be used when you don't
know what will be thrown.

Cheers.
Chris Val

[Klaus Eichner]

"Chris ( Val )" <ch******@bigpond.com.au> wrote in message
news:bf************@ID-110726.news.uni-berlin.de...

"Klaus Eichner" <kl******@yahoo.com> wrote in message
news:3f**********************@news.free.fr...
| "Jacques Labuschagne" <ja*****@clawshrimp.com> wrote in message
| news:2360088.KJvXMtpkjA@klesk...
| > Peter van Merkerk wrote:

[snip]

| > I'm not trying to say otherwise. Allow me to
| > rephrase my sentence:
| > "When all other attempts at deducing the actual type of an exception have | > failed, why not try std::exception which is the base of all exceptions
| > generated by the standard library".
|
| ...because std::exception is the base _only_ of exceptions generated by the | standard library (derived from std::exception) . There are, however, many, | many more exceptions which are not derived from std::excteption, but still | can be thrown, for example
|
| class MyError{};
| throw MyError();
|
| The most general form is still catch(...).

Are you saying that 'catch( ... );' should be used ?

...rather than: catch( const MyError& e ); ?
Yes, the reasoning behind that is as follows:

- it is not guaranteed that a compiler generates code such that an exception
is thrown if an arithmetic exception (such as "divide by zero") is
encountered during run-time.
AFAIU, the former should only be used when you don't
know what will be thrown.
- if the compiler generates such code, it is not known of what type the
exception is, in particular we don't know whether or not this exception is
derived from std::exception.
Cheers.
Chris Val

[Klaus Eichner]

"Chris ( Val )" <ch******@bigpond.com.au> wrote in message
news:bf************@ID-110726.news.uni-berlin.de...

"Klaus Eichner" <kl******@yahoo.com> wrote in message

[snip]

| > | class MyError{};
| > | throw MyError();
| > |
| > | The most general form is still catch(...).
| >
| > Are you saying that 'catch( ... );' should be used ?
| >
| > ...rather than: catch( const MyError& e ); ?
|
| Yes, the reasoning behind that is as follows:
|
| - it is not guaranteed that a compiler generates code such that an exception | is thrown if an arithmetic exception (such as "divide by zero") is
| encountered during run-time.

That part I know, I wasn't questioning this aspect of it :-).

| > AFAIU, the former should only be used when you don't
| > know what will be thrown.
|
| - if the compiler generates such code, it is not known of what type the
| exception is, in particular we don't know whether or not this exception is | derived from std::exception.

I was asking, why you would use only 'catch( ... );', rather
than 'catch( const MyError& e );', because, if you use a
conditional check, then you get to choose the exception
thrown.

For example:

try
{
int a = 0, b = 9;
if( a == 0 )
throw MyError( "Divide by zero encountered. " );

b /= a;
}
catch( const MyError& e )
{
cout << e.what() << endl;
}
catch( ... )
{
cout << "Something unknown happened" << endl;
}

I am asking, why use only 'catch( ... );' for the above, when
1) it won't catch it,
if 'catch(...)' won't catch it, then nothing will catch it. i.e. there is no
solution to the problem, but we don't know, but at least we can try.
2) we know that MyError will get caught
in the handler specified,
This is not true in the original example. It only works in your example
where you added an '...if ( a == 0 ) throw (MyError("xxx"));...', but this
was not the original scenario. The original scenario was a program which
performed a simple division.

I think here is where the confusion starts:

I introduced 'MyError' in a previous post:
=== There are, however, many,
=== many more exceptions which are not derived from std::excteption, but
still
=== can be thrown, for example class MyError{};

What I wanted to say is that the *compiler* is allowed to throw an exception
of any type, even 'MyError' is allowed (where 'MyError' is a compiler
specific exception type)

Of course, I didn't express myself clearly, and you assumed that 'MyError'
was thrown as part of an '...if ( a == 0 ) throw (MyError("xxx"));...' in a
modified version of the C++ program.

I must apologise for the inaccurate post previously, and I hope that my post
is now clearer.
and 3), it should only be used for
*unknown* exceptions that *can* be handled as a C++ exception,
as a safety net being the last handler in the try/catch mechanism.
that's exactly the situation described in the original example: a C++
compiler can generate code such that the program execution throws an
exception if it encounters a "divide by zero", but it is not required by the
standard to do so. Furthermore, in case an exception is thrown, the standard
does not require a specific type of exception.

In other words: The exception (if it is thrown at all) in the original
example is *unknown*.

As you corectly said, 'catch(...)' should be used for those unknown
exceptions as a safety net.
Having it as the last handler above is ok, because I know for this
particular 'div by zero' error, 'MyError' will be caught. The only
reason for the last handler, is to catch the catchable unknown.

Cheers.
Chris Val

[Chris \( Val \)]

"Klaus Eichner" <kl******@yahoo.com> wrote in message
news:3f**********************@news.free.fr...
| "Chris ( Val )" <ch******@bigpond.com.au> wrote in message

[snip]

| What I wanted to say is that the *compiler* is allowed to throw an exception
| of any type, even 'MyError' is allowed (where 'MyError' is a compiler
| specific exception type)
|
| Of course, I didn't express myself clearly, and you assumed that 'MyError'
| was thrown as part of an '...if ( a == 0 ) throw (MyError("xxx"));...' in a
| modified version of the C++ program.
|
| I must apologise for the inaccurate post previously, and I hope that my post
| is now clearer.
|
| > and 3), it should only be used for
| > *unknown* exceptions that *can* be handled as a C++ exception,
| > as a safety net being the last handler in the try/catch mechanism.
|
| that's exactly the situation described in the original example: a C++
| compiler can generate code such that the program execution throws an
| exception if it encounters a "divide by zero", but it is not required by the
| standard to do so. Furthermore, in case an exception is thrown, the standard
| does not require a specific type of exception.
|
| In other words: The exception (if it is thrown at all) in the original
| example is *unknown*.
|
| As you corectly said, 'catch(...)' should be used for those unknown
| exceptions as a safety net.

You're right, I did misinterpreted what you were trying to explain <g>.

I agree with what you have stated.

Cheers.
Chris Val

PS: Sorry about the late reply, I completely forgot
about this thread :-).