Thanks to your advices and remarks, I have updated the verbose_exception class with the execinfo gcc feature (http://tmetz.free.fr/verbose_exception-0.5-1.tgz).
Unlike what I though, execinfo is independent of the debugger flag (execinfo is enabled with -rdynamic flag). So the stack info can be added with minimum size overhead (1 to 5 %). With this new version it becomes useless to add a macro at each function / method (in fact it is not fully equivalent because execinfo does not trace inline functions) So > > Inconvenients : > > - a VE_CATCH_RETHROW macro shall be added on all methods / > This is practically a killer. No one (I think) will add this, it is > way too inconvenient and intrusive (and I guess also a performance > slower.) It is no more true. What's your new feeling ? As it can be really easy to add stack info, what about to add something similar in glibmm API ? Thomas Le Mardi 26 Septembre 2006 22:28, Thomas Metz a écrit : > > > > This is practically a killer. No one (I think) will add this, it is > > > > way too inconvenient and intrusive (and I guess also a performance > > > > slower.) > > Maybe. The idea it's just to provide another way to the developer for > debugging at runtime, it's up to him to decide if he wants to use it > completly, partially (without the stack trace or limited stack trace) or > not at all. > > So if VE_CATCH_RETHROW macros are not added, with the line : > > VE_THROW_VERBOSE_EXCEPTION(bad_format, > "Unable to read " << fileName << " " > << fileId << " : " << VE_WHAT); > > you will get : > Unable to read myFile.bin 2 : bad_format > while executing "int test_ex ()" (file test_verbose_exception.cpp line 42) > > On my point of view, it is a simple way to get lots of information. > > Sometimes with some applications you feel alone. Just : time-out, invalid > parameter, internal error, interrupt system call. It's difficult to find > the problem, even with the code. > In most of case (85%) you don't care, you just have to restart the > application, but in some applications a little more critical (client / > server / distributed apps), you have to explain what's happened. It's often > hard. > > > > I've know of a guy that did something with similar functionality but a > > > better implementation. > > Indeed the execinfo.h is interresting but is seems to be limited to gcc > (for me not a problem) an it certainly requires the debugging information. > if yes, it's a pity, the goal is not to debug the code (it's supposed to be > already done), but to find easily the trouble source (origin) when an error > occurs. Else I agree, it is a cleaner / simpler implementation. > > >> like this idea. But what about a structure like this: > >> > >>#ifndef DEBUG_VE_USE_EXCEPTIONS > >> #define VE_THROW_???_???(..., info, ...) \ > >> std::cerr << info << std::endl; > >> > >>#else DEBUG_VE_USE_VERBOSE_EXCEPTIONS > >> #define VE_THROW_???_???(..., info, ...) \ > >> /* the verbose exception */ \ > >> ... \ > >> ... > >>#endif > > I assume that you mean to print automatically to stderr => indeed it can be > added. > > > Thomas > > Le Vendredi 22 Septembre 2006 23:03, Paul Davis a écrit : > > Oops, forgot a keyword... > > > > On 9/22/06, Paul Davis <[EMAIL PROTECTED]> wrote: > > > I've know of a guy that did something with similar functionality but a > > > better implementation. > > > > > > http://www.slamb.org/svn/repos/trunk/projects/atoms/atoms/debug.cc > > > > > > This is an implementation of a Backtrace class that can be > > > conditionally included in throw exceptions ( He has it compile > > > conditional ) > > > > > > It does depend on the compiler and system though. Specifically, the > > > header execinfo.h ( Which I assume to be a standard gcc extension ). > > > Although, execinfo might not exist on other platforms or for other > > > compilers. > > > > I'm NOT very knowledgable as to all the other compilers and the backtrace > > accessibility. > > > > And, its not like you get anything more than you'd get from gdb. So, > > unless > > > > > you've got a huge project with at least hundreds of installations and > > > want to implement some sort of automatic backtrace report on crash > > > capability, I don't really see the need. > > > > > > But, I'll have to agree with the other Paul, wrapping code in try/catch > > > blocks is not the way to go (And is generally a Bad Idea). > > > > > > Hope that helps, > > > > > > Paul > > > > > > On 9/22/06, Paul Pogonyshev <[EMAIL PROTECTED]> wrote: > > > > Thomas Metz wrote: > > > > > Inconvenients : > > > > > - a VE_CATCH_RETHROW macro shall be added on all methods / > > > > > functions > > > > > > > > This is practically a killer. No one (I think) will add this, it is > > > > way too inconvenient and intrusive (and I guess also a performance > > > > slower.) > > > > > > > > Paul > > > > _______________________________________________ > > > > gtkmm-list mailing list > > > > [email protected] > > > > http://mail.gnome.org/mailman/listinfo/gtkmm-list > > _______________________________________________ > gtkmm-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gtkmm-list _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
