lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Unable to close lmi (resolved)


From: Greg Chicares
Subject: Re: [lmi] Unable to close lmi (resolved)
Date: Tue, 30 Dec 2008 17:33:02 +0000
User-agent: Thunderbird 2.0.0.18 (Windows/20081105)

On 2008-12-30 16:38Z, Vadim Zeitlin wrote:
> On Mon, 29 Dec 2008 05:27:38 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> [I believe I've solved this problem. It's documented here just
> GC> for the record.]
> GC> 
> GC> This message:
> GC>   http://lists.nongnu.org/archive/html/lmi/2008-12/msg00016.html
> GC> describes one way to reproduce a situation where an exception is
> GC> thrown in a class ultimately derived from wxView.
> 
>  Sorry for failing to look at the original before, I'm rebuilding LMI to do
> it right now -- from what I can see, even though you did fix the problem in
> LMI so far it's still not clear why did the behaviour change in 2.8.9 and
> I'd like to understand this.

To clarify, there were two distinct problems:

  http://lists.nongnu.org/archive/html/lmi/2008-12/msg00016.html
  "Suspected wx-2.8.9 regression"
I do seek your insight there. Although I presented it in terms
of lmi, I originally observed it in the automated GUI tests in
a different trunk:
  http://cvs.savannah.gnu.org/viewvc/lmi/skeleton/mvc_test.cpp?view=markup
I've updated that trunk's "raw" makefiles so that they build
with Cygwin, but I suppose the autotools stuff there needs work.
Anyway, except for this issue, all those GUI tests pass with
wx-2.8.9, which is good to know; I must endeavor to build and
run those tests more frequently, because they're an inexpensive
way to find issues we might otherwise overlook.

The other problem is:
  http://lists.nongnu.org/archive/html/lmi/2008-12/msg00017.html
  "Unable to close lmi (resolved)"
That's this thread, resolved thus:

> GC> The ultimate cause is that IllustrationView::OnCreate(), an
> GC> overridden virtual, can throw an exception (as in the situation
> GC> above)--but it needs to return 'false' to prevent the doc-view
> GC> framework from creating a zombie view.

and I'm sure that was my fault: I violated the contract of
wxView::OnCreate() by failing to return 'false'. IOW, wx
doesn't offer the "strong" exception-safety guarantee
  http://www.boost.org/community/exception_safety.html
and I shouldn't write code as though it did.

> GC> I'll address the observed problem narrowly now, by trapping that
> GC> particular exception. A general solution could require a fairly
> GC> extensive rewrite, trapping all exceptions in potentially any
> GC> overridden wx function that doesn't return 'void'.
> 
>  Even although doing it in wx is not much simpler, I'd still prefer to do
> it there because at least like this it will have to be done only once. So
> I've just checked in the following change:
> 
>       http://trac.wxwidgets.org/changeset/57671
> 
> which could be backported (in a slightly modified form) to 2.8 branch if
> you think this would be useful for LMI. Please let me know if you do.

I don't see any need to backport it, but thanks.

Actually, I'm not sure how that changeset could resolve the
(former) problem in lmi, which was due to an exception that
got caught far away. How could that be solved without writing
try...catch?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]