Some ffis do this to present C++ stack traces to their host languages.
If variables/frames are optimized out, then yes, you can't display their contents. But anyone that has used gdb already knows this...
I work with projects where stack traces are added automatically to exceptions during throw. It works quite well, and in fact I would disagree with author on some of his points:
- stack trace not representative of source code, due to optimizations - unwinding information is consistent with what you have in a source code, and compiler optimization don't change that (i.e., it would be a compiler bug if it did, see any design document about debugging information, for example in LLVM / Clang).
- throw expression is not a place where the problem is - that is of course true in general, but how much more useful is stack trace indicating code path where exception have been thrown, than merely a type of exception. Name of function which have thrown an exception is also a good start, but of limited value for some common utility functions.
- memory allocation - dynamic memory allocation could be problematic, but storing stack trace in exception object itself is quite simple and avoid this problem altogether.
Because modern optimizations make that impossible. (How do you represent a statement that GVN eliminated, for example?) Not doing those optimizations would make code unacceptably slow.
(and with "structured exception handling" and a bit of hacking, you can get backtraces for machine exceptions as well)