Re: [lmi] Changes in error handling

[Greg Chicares]

On 2006-1-8 14:13 UTC, Vadim Zeitlin wrote:
> On Sat, 17 Dec 2005 08:03:20 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Vadim--Looking back, it strikes me that this code in 'main_wx.cpp'
> GC> is fragile:
> GC> 
> GC>   bool Skeleton::OnExceptionInMainLoop()
> GC>   {
> GC>       try
> GC>           {
> GC>           // This just rethrows the exception. For msw at least, it
> GC>           // seems crucial that the exception be thrown from the same
> GC>           // shared library that caught it. This works only with a
> GC>           // 'monolithic' wx shared library.
> GC>           return wxAppConsole::OnExceptionInMainLoop();
> GC>           }
> GC> 
> GC> Is there a way to assert, in C++, that we have a monolithic wx build?
> 
>  Not currently. We could define a special macro when building wx in this
> mode (__WXMONOLITHIC__?) but it would be far better to make it work in all
> cases, of course.
> 
> GC> Particularly if not, I think there's a strong case for providing a
> GC> simple 'rethrow' function like wxAppConsole::OnExceptionInMainLoop()
> GC> in the GUI subsystem of wx.
> 
>  Actually it looks that OnExceptionInMainLoop() would have to be simply
> moved to wxAppBase from wxAppConsole as currently it's not used at all by
> console applications. And if the console applications ever do get their
> main loop, then the calls to OnExceptionInMainLoop() (and hence "catch"
> clauses) would be in the base lib too.
> 
>  So I moved this function to wxAppBase now, hopefully it should fix the
> problem in non-monolithic build.

Thanks, that's great.

> GC> Here's a documented test case:
> GC>   http://sourceforge.net/mailarchive/message.php?msg_id=14203568
> GC> that shows the underlying problem in a simplified way;
> 
>  It's a pity there were no replies to this message... I'd really like to
> know/understand why doesn't this work.
> 
> GC> I don't know whether this is specific to gcc.
> 
>  At least it doesn't happen with msvc.

Actually, there were replies, but sourceforge doesn't make that obvious.
I think this is the one you had hoped to see:

  http://sourceforge.net/mailarchive/message.php?msg_id=14223374

wherein one of the gcc-msw maintainers addresses it as a defect and
proposes two different solutions. I had suspected that this valuable
idiom just wasn't supposed to work across a dll boundary, but that's
not the way he sees it at all, so I'm glad I asked there.

This is yet another reason why lmi should be made to build with more
than one compiler.