C++ retrieve exception information

Question

I have a c++ dll which I need to debug. Due to the circumstances in which I am using the dll, I am unable to debug it via the calling application.

So, I created a try -catch, where the catch writes the exception to a file.

The line which needs to be debugged involves imported classes from a 3rd party dll, so I have no way of knowing what type of exception it is. When I tried catch(exception e), no message was written to the file. So I tried catch(...), which did trigger something:

using std::exception::what, the only thing that got written to the file was "1". using std::exception::exception, the file received the following code : "0579EF90".

Is there any way for me to retrieve meaningful info about the exception that was thrown?

TIA

CG

Answer 1

If you don't use catch(KnownExceptionType ex) and use your knwoledge about KnownExceptionType to extract info, no you can't.

When you catch with catch(...) you are pretty much lost, you know that you handled an exception but there is no type information there, there is little you can do.

You are in the worse case, an exception coming out from a library, you have no info on the exception, even if you had headers for the lib, that exception type doesn't need to be defined there.

Answer 2

maybe try catching std::exception & e

1. std::cout << e.what() << endl;
2. see if you can cast it to std::logic_error, and std::runtime_error - that should give you some clue what you're dealing with

Answer 3

If I understand you correctly, you've already narrowed down the source of the issue to a specific call to a 3rd party library, but you're not allowed to debug the application live (do I want to ask why?), and your question is "how can I debug the exception without any knowledge of what the exception is"

The answer is, you can't. As you observed, you can blindly guess and hope to catch the right thing. You can also catch(...), but that will tell you exactly nothing. If you could debug live, you could set the debugger to break when the exception is thrown and see what is going on there.

I think the right answer though is to contact the 3rd party library you've narrowed down the source of the issue to and ask them. It is very, very bad form to throw an exception and allow it to propogate across module boundries. It makes me suspect that it's a Windows SEH exception for a null pointer deref or something, and you're compiling in such a way that catch(...) catches those.

Answer 4

Firstly, you should always catch exceptions by const reference, in other words:

catch( const std::exception & ex ) {
  ...
}

Not doing so means that your exceptions will be of the exact type you catch and this may result in the loss of exception information.

However, it seems that your library is throwing something not derived from std::exception - you need to find out what the type (ideally the base type) is.

Answer 5

I'm a bit confused. On the one hand you write catch(std::exception) didn't work (you should use catch(const std::exception&), BTW), on the other hand you also write you invoked std::exception::what(). How did you do this if you didn't have a std::exception in the first place?

Anyway, once you have caught anything but ..., you could try to log the RTTI info:

#include <typeinfo>

try {
  foreign_code(my_data);
} catch(const some_type& x) {
  std::cerr << "Yikes! Caught exception of type '" 
            << typeid(x).name() 
            << "' with its hand in the cookie jar!\n";
  std::abort();
}

While the standard doesn't make any assumptions of the result of std::type_info::name(), most (if not all) compilers will generate code that emits something that's at least somewhat useful.

When you're inside the VS debugger, you could also set it up so that it will stop at any exceptions thrown. That gives you a stack trace and thus might give you a clue as to what data passed to the DLL could have cause the problem.