Getting info about an unknown exception

[Adem]

Is it possible to get some info about an unknown exception,
ie. the "catch (...)" case below:

catch (const blah1 &ex)
{
cout << "blah1 exception." << endl;
}

catch (const blah2 &ex)
{
cout << "blah2 exception." << endl;
}

catch (...)
{
cout << "unknown exception." << endl;
}

Can one get for example the line number where the
unknown exception was thrown?

 

[Kai-Uwe Bux]

Is it possible to get some info about an unknown exception,
ie. the "catch (...)" case below:

catch (const blah1 &ex)
{
cout << "blah1 exception." << endl;
}

catch (const blah2 &ex)
{
cout << "blah2 exception." << endl;
}

catch (...)
{
cout << "unknown exception." << endl;
}

Can one get for example the line number where the
unknown exception was thrown?

No.

a) All information used at the point of the catch has to be stored in the
thrown object (simply because that is the only one not subject to stack
unwinding). And, for all you know, what is caught in the (...) catch clause
could be a char.

b) If you find yourself wishing for that option, chances are that your
design needs fixing. What is the underlying problem you are trying to
solve?


Best

Kai-Uwe Bux

 

[Adem]

No.

a) All information used at the point of the catch has to be stored in the
thrown object (simply because that is the only one not subject to stack
unwinding). And, for all you know, what is caught in the (...) catch clause
could be a char.

b) If you find yourself wishing for that option, chances are that your
design needs fixing. What is the underlying problem you are trying to
solve?

I compiled a huge project of someone else.
The program's main() ends like that given above.
Too bad, since it is a huge project it seems not easy
to find the location of that error. :-(

 

[Kai-Uwe Bux]

I compiled a huge project of someone else.
The program's main() ends like that given above.
Too bad, since it is a huge project it seems not easy
to find the location of that error. :-(

Running that thing in a debugger might help. Most can give you a stack
trace. That way, you can find the location where the throw happens.


Best

Kai-Uwe Bux

 

[Salt_Peter]

Is it possible to get some info about an unknown exception,
ie. the "catch (...)" case below:

catch (const blah1 &ex)
{
cout << "blah1 exception." << endl;
}

catch (const blah2 &ex)
{
cout << "blah2 exception." << endl;
}

catch (...)
{
cout << "unknown exception." << endl;
}

Can one get for example the line number where the
unknown exception was thrown?

No, unless you equip the program to do so (add relevent catch clauses
to capture other specific exceptions). In the case where standardized
exceptions come into play, at least add a catch block for
std::exception. If coders stuck to using the existing hierarchy, life
would be much simpler, ie:

#include <iostream>
#include <stdexcept>

// std::runtime_error is a derivative of std::exception
class SomeException
: public std::runtime_error
{
public:
SomeException( const char* ps )
: std::runtime_error( ps ) { }
};

int main()
{
try
{
throw SomeException("error in main()");
}
catch( const std::exception& e )
{
std::cout << e.what() << std::endl;
}
catch( ... )
{
std::cout << "unknown exception\n";
}
}

/*
error in main()
*/

 

[Bart van Ingen Schenau]

Running that thing in a debugger might help. Most can give you a stack
trace. That way, you can find the location where the throw happens.

Commenting the catch(...) clause (temporarily) out may give the
debugger and you an easier time in locating the throw point.
If an exception is not caught at all, the debugger may kick-in
immediately when the throw-expressing is to be executed.
If there is a matching catch-clause, the debugger can only kick-in
when it hits a manually set breakpoint, which you can only set
correctly if you already know where the exception might be coming
from.

Best

Kai-Uwe Bux

Bart v Ingen Schenau

 

[James Kanze]

[...]

No.

a) All information used at the point of the catch has to be
stored in the thrown object (simply because that is the only
one not subject to stack unwinding). And, for all you know,
what is caught in the (...) catch clause could be a char.

b) If you find yourself wishing for that option, chances are
that your design needs fixing. What is the underlying problem
you are trying to solve?

Most likely, he's dealing with a poorly documented third party
library. Which is throwing exceptions without documenting the
fact.

 

[red floyd]

Is it possible to get some info about an unknown exception,
ie. the "catch (...)" case below:

[...]

No.

a) All information used at the point of the catch has to be
stored in the thrown object (simply because that is the only
one not subject to stack unwinding). And, for all you know,
what is caught in the (...) catch clause could be a char.

b) If you find yourself wishing for that option, chances are
that your design needs fixing. What is the underlying problem
you are trying to solve?

Most likely, he's dealing with a poorly documented third party
library. Which is throwing exceptions without documenting the
fact.

Or, he could be dealing with Windows, which throws (...) for system errors.

 

[Stephen Horne]

Can one get for example the line number where the
unknown exception was thrown?

Here's one creative approach...

1. Make damn sure you have a safe unmodified copy of the original
source. Visual differencing tools are also likely to come in
handy.

On Windows, I'd just make a temporary subversion repository and
commit the original sources, using TortoiseSVN. That makes it easy
to diff any changes I make in the working copy.

2. Search all files, and replace every throw with some other code,
such as printing the value of __LINE__ then exiting. Anything
along those lines - the details will depend on the platform and
the application.

3. Run, check the exception that gets thrown, and restore each
exception throw when you're sure it's not the problem (exceptions
are not always errors, or at least they may already be handled
correctly).

You're far better off with a debugger, but this kind of approach can
help at times.


BTW - commenting out your catch(...) blocks may also help when
debugging. It converts a caught exception into an uncaught one, which
the debugger is more likely to break at by default.