J
Jacques Labuschagne
Gary.Hu said:
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.
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.
P
Peter van Merkerk
Jacques Labuschagne said:
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".
J
Jack Klein
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
C
Chris \( Val \)
| 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
| 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
J
Jacques Labuschagne
Peter said:
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".
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.
K
Klaus Eichner
catch(...) catches all exceptions, but it does not catch a 'Divide by zero'Jacques Labuschagne said:
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)
....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(...).
G
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?
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?
C
Chris \( Val \)
| | > 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
[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
K
Klaus Eichner
Chris ( Val ) said:
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.
- 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.
K
Klaus Eichner
Chris ( Val ) said:[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.
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.
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.
C
Chris \( Val \)
[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.
| 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
.