Re: need argument for try catch blocks
"Edek" <edek.pieITAKNIECZYTAM@gmail.com>
Is it possible to do anything which may throw during stack unwind? I
always thought that was UB.
Depends. If you use the standard library, it states that you'll have UB if
your type T emits an exception from a destructor.
In general that is not UB, but a double exception will end up in
terminate(). And a throwing destructor can leave behind memory leaks,
incosistencies and much other stuff you do not want. for that reason it is
a strong guideline that destructors must be nothrow. Those ignoring it are
likely in peril regardless other stuff.
c) to log, if there are no stack traces and for some reason a debugger
cannot be used, or just it is quicker to have a log without plugging
in a debugger
Logging is a suspicious reason, and if really needed also can be done
better in a RAII-like form. Though special cases may apply.
Like having no exception stack trace? Hell, I like getting at the top of
the thread an information along the lines of 'Integer conversion failed'
and nothing more.
If you write correct software, you will not have that. If it is caused by
not software but input external input, then you can dump the input at that
place, and figure out why it was not fit for purpose.
As I told before, chasing more log and traci is a usual activity that
correlates tith WTF-ish codebase. The rrot fix of that is not adding more
trace support but start work on reviews and fixes.
Whily really hairy environments support externally controllable trace. Like
the linux kernel -- you can echo > to turn on tracepoints, debug messages on
a single module, or even on a single line of source if interested. And it is
NOT there for the regular case. Neither needs excess code for tracing (only
for special messages).
And adding noise to the code provably hinders making it right. While making
it simpler and easier to read leads to less problems to look after. Or
putting the same effort into unit tests will more likely find the cause of
your integer conversion.