On Tue, Jun 2, 2009 at 5:26 PM, Emil Dotchevski <emildotchevski@gmail.com>wrote:
On Tue, Jun 2, 2009 at 5:08 PM, Emil Dotchevski < emildotchevski@gmail.com>wrote:
Adding stack trace support to Boost Exception was also discussed at BoostCon, it would definitely be a nice addition to the rest of the information recorded in Boost exceptions automatically by BOOST_THROW_EXCEPTION.
I'm guessing that the stack trace information could be stored in boost::exception as a little more than just a list of pointers to functions, and converted to string at the catch site. Of course this support should be kept separate from Boost Exception, IMO a simple interface like this would be ideal:
namespace boost { namespace debug { class stack_trace; shared_ptr<stack_trace> get_stack_trace(); std::string to_string( stack_trace const & ); } }
I do agree that at a bare minimum it should provide a to_string() function, but actually so much more than this is possible. The rudimentary support for this that I've implemented so far already can determine how many parameters a function has, its return type, the names of the arguments,
types of the arguments, the values of each parameter. So it would definitely be nice to provide iterators for these types of things, and accessors / enumerations to determine what data type something is, names of symbols, etc. This way (among other things, such as the file / line number / overloaded new and delete issue I mentioned in the previous post) someone could provide a custom formatter for a stack trace if they didn't like
On Tue, Jun 2, 2009 at 3:17 PM, Zachary Turner <divisortheory@gmail.com> wrote: the the
default.
I can't think of a use case for wanting anything but a string, to be dumped into a bug report of some sort. You might need more than that if you want this interface to be powerful enough to implement a full featured debugger or whatever, but that's a different problem domain altogether. So I'd keep the stack trace interface simple and to the point.
Well, ok for the stack trace interface itself I can agree with that. Most of the other functionality will end up getting implemented one way or another though, otherwise it wouldn't be possible to generate a stack trace in the first place. So would it be worthwhile to expose the other functionality, even if through some other interface than a stack trace? For example, the stack_trace class internally may need to create some objects of type symbol which contain references to the module_info the symbol is contained in, the name of the symbol, source/line number, virtual address, etc. This interface could be exposed as well, since it's going to have to probably be written anyway. Also, I think it's useful to at the very least be able to iterate the stack frames and find source/line number information for each call in stack.