How to identify exception ?

J

Jarek

Hi all!

Is it possible to identify throw statement, within catch( ... )?
Can I identify type of exception passed to catch(...) ?
I'm trying to identify problem, which is probably somewhere in library
which I'm using.
This is real-time program, so step-by-step debbuging is very diffcult.
Program is written in gcc-3.3 working on Linux

best regards
Jarek.
 
B

benben

Hi all!
Is it possible to identify throw statement, within catch( ... )?
Can I identify type of exception passed to catch(...) ?
I'm trying to identify problem, which is probably somewhere in library
which I'm using.
This is real-time program, so step-by-step debbuging is very diffcult.
Program is written in gcc-3.3 working on Linux

best regards
Jarek.

If all you can do to catch the exception is through catch(...) then the only
assumption your handling code should make is that an exception is thrown. If
the exception itself is polymorphic and you know the base type then you can
use RTTI (e.g. dynamic_cast, typeid(), etc)

ben
 
B

binbag

I'm not recommending this approach but...
If you explictly throw then you can use the __LINE__ and __FILE__
preprocessor directives either to create an object, or if you are
abandoning any sanity set a global variable.
If you do this, then I wany joint credit in the obfuscated C++ contest
:)
 
J

Jarek

benben said:
If all you can do to catch the exception is through catch(...) then the only
assumption your handling code should make is that an exception is thrown. If
the exception itself is polymorphic and you know the base type then you can
use RTTI (e.g. dynamic_cast, typeid(), etc)

The problem is that I don't know anything about this exception. I tried
few catch-es (exception, char *, etc), but no one can match.

Is there some tool to analyze to analyze code to find all throws ?
Something like in eclipse for java ?

best regards
Jarek
 
B

benben

The problem is that I don't know anything about this exception. I tried
few catch-es (exception, char *, etc), but no one can match.

So doesn't the library documentation specifies the types to be thrown? also
check exception specification in function declarations.
 
J

Jarek

So doesn't the library documentation specifies the types to be thrown? also
check exception specification in function declarations.

It is not clear, and code doesn't match manuals.

I'm studying now what Bjarne Stroustrup in his C++ book is thinking
about this :)

Thank you are any sugestions.
best regards
Jarek.
 
B

benben

I think, as benben said, your best bet is to use RTTI.
But RTTI relies on a pointer being thrown. Most systems don't throw pointers
anymore.

That's why it is always a good idea to have an exception hierarchical
exception family...

Ben
 
M

msalters

benben schreef:
But RTTI relies on a pointer being thrown. Most systems don't throw pointers
anymore.

No it doesn't. RTTI works on pointers and references. You can catch
by reference, so that will allow you to catch non-pointers. That
doesn't
solve an undocumented exeption/catch(...) problem, though.

HTH,
Michiel Salters
 
B

benben

No it doesn't. RTTI works on pointers and references. You can catch
by reference, so that will allow you to catch non-pointers. That
doesn't
solve an undocumented exeption/catch(...) problem, though.

HTH,
Michiel Salters

But you can't have a void& can you. The fact is, dumping the exception
requires assumption on where the exception object is actually stored.

Ben
 
M

msalters

benben schreef:
But you can't have a void& can you.

No, of course not. Why do you even ask? You can't dereference void*
either, and neither void* or void& are related to exceptions.
The fact is, dumping the exception
requires assumption on where the exception object is actually stored.

Nope. An implementation doesn't have to store an exception object. So,
assuming the exception object has an address is wrong. Furthermore,
even if an object is stored, it may not contain RTTI information. And
even if it did, you'd still need to know a base class

HTH,
Michiel Salters
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,770
Messages
2,569,584
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top