Hi,
Another one of these c++ constructs that make me go ehe? questions...
Just wondering why there are these try-catch-throw constructs in
dwarf_edit and dwarf_output. They do some cleanups, but there isn't any
"recatcher" for the failures, so effectively all they do is hide the
root cause when something goes wrong. But I might be missing something.
To help my own debugging I have removed them on my branch.
Cheers,
Mark
Show replies by date
The thing to remember is that all of this code is library APIs.
As such, the only proper way for failure cases to be is that they
leave library-maintained objects in states that won't cause the
library code to freak out in further use, don't leak memory, etc.
The exceptions we see today as we hack are all due to bugs. But in
general, there can be exceptions that result from libdw errors due to
malformed input files, allocation failures, etc. We haven't bothered to
catch anything in our utility programs just because we haven't bothered,
and because we also haven't bothered to define proper API-worthy exception
types and so forth. But in production-ready code, the utilities would
catch exceptions and turn them into graceful errors (some of which might
even be non-fatal).
For debugging, what you want to use is gdb's "catch throw" and/or "b
__cxa_throw" (the real name of the internal runtime function that all
C++ throw clauses lead to--I used to use that because "catch throw"
was not always reliable, but I think gdb has gotten better that way).
This is akin to using "b abort". You want to intercept the failures
at the precise time they are diagnosed, before any cleanup/recovery
code has run to perturb or obscure the state of the program. In my
~/.gdbinit I have:
define catch crash
catch throw
b abort
b __assert_fail
b __assert_perror_fail
b __GI___assert_fail
end
document catch crash
Set breakpoints for C++ throw, assertion failures, abort calls.
end
Thanks,
Roland