Re: verbose exception

[Thomas Metz <tmetz free fr>]

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 <pjdavis engineering uiowa edu> 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 <pogonyshev gmx net> 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
> > > > gtkmm-list gnome org
> > > > http://mail.gnome.org/mailman/listinfo/gtkmm-list
>
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list