[UTF] Let my debugger catch unhandled exceptions
Hi all, I'm trying to track down a problem in my code that the Boost test framework has isolated, however I'm finding it difficult to track it back to a line in the source. The Boost test framework likes to catch all exceptions, which means when you run the code through a debugger it doesn't break at the point the exception becomes unhandled, so you can't do a backtrace to see where it came from. There is the option --catch_system_errors=no which works for some exceptions, but not these ones. I'm using gdb and telling it to "catch throw" is painful because there are dozens of exceptions thrown around correctly before it gets to the unhandled one I'm interested in. Is there some easy way I can tell UTF not to catch any exceptions? Many thanks, Adam.
Adam Nielsen <a.nielsen <at> shikadi.net> writes:
Is there some easy way I can tell UTF not to catch any exceptions?
No. You can't tell UTF not to catch c++ exceptions. What you can do though is to run your test with log_level=message and see last statement executed before the exception is thrown, set a break point there and turn on 'catch throw' only after you've got to this point. Gennadiy
No. You can't tell UTF not to catch c++ exceptions.
What you can do though is to run your test with log_level=message and see last statement executed before the exception is thrown, set a break point there and turn on 'catch throw' only after you've got to this point.
Thanks for the suggestion. Unfortunately this only gives me the line number of the last BOOST_xxx macro executed, whereas the exception is thrown from deep within the code, long after the last BOOST_xxx macro has been used. It sounds like I might have to delve into the UTF source, perhaps if I can put an assert(false) when UTF handles an exception that might work, as assertion failures seem to be accessible through the debugger without any trouble. Cheers, Adam.
Adam Nielsen wrote:
No. You can't tell UTF not to catch c++ exceptions.
What you can do though is to run your test with log_level=message and see last statement executed before the exception is thrown, set a break point there and turn on 'catch throw' only after you've got to this point.
Thanks for the suggestion. Unfortunately this only gives me the line number of the last BOOST_xxx macro executed, whereas the exception is thrown from deep within the code, long after the last BOOST_xxx macro has been used.
It sounds like I might have to delve into the UTF source, perhaps if I can put an assert(false) when UTF handles an exception that might work, as assertion failures seem to be accessible through the debugger without any trouble.
What compiler are you using? MSVC has a setting that allows you to break on exceptions at the point of throw. I usually put a break near the area of concern, then set Break when an std::exception is thrown. I'm not sure which other compiler/debuggers have this facility though. Jeff
What compiler are you using? MSVC has a setting that allows you to break on exceptions at the point of throw. I usually put a break near the area of concern, then set Break when an std::exception is thrown. I'm not sure which other compiler/debuggers have this facility though.
Thanks for the suggestion. I'm using GCC and GDB and it can do this as well, but the problem is I get too many nuisance breaks because there are a bunch of exceptions clustered together. I don't know which one is the problem one so it's very tedious investigating dozens of them until you find the one you want! Cheers, Adam.
participants (3)
-
Adam Nielsen -
Gennadiy Rozental -
Jeff Flinn