Re: [lmi] Untimely "save" dialog [Was: wxmsw-2.9.0 regression: crash when a messagebox should appear]

[Greg Chicares]

On 2009-03-13 20:03Z, Greg Chicares wrote:
> On 2009-03-09 20:23Z, Vadim Zeitlin wrote:
> [...]
>> Notice that an alternative could be to move Run() inside try/catch clause
>> instead but it seems inconsistent to catch only some exceptions and not all
>> of them, even if now (i.e. with my latest changes to wx) catching them or
>> letting them escape shouldn't change the observable behaviour.
> 
> I'm not sure whether this is worth examining, but I'll just report it
> and let you decide. I experimentally made a flawed change, and got a
> crash. I'm still using snapshot 'wxWidgets-2009-03-12.tar.bz2', BTW.

[snip an idea that I now repudiate]

> I say this is flawed because it calls OnCreate() repeatedly for the
> same document. I believe I should instead refactor Run() into two
> private functions, to be used here thus:
>   EditProperties();
>   ThePartOfRunThatDetectsInvalidInput(); // validate and calculate
>   OnCreate(...);
>   TheOtherPartOfRun(); // show calculation results in wxHtml

That would only compound the flaw. Indeed, this is the worst of
programming sins: adding complexity through wasting effort on
palliative relief of symptoms, while leaving the root cause
unaddressed.
 - We wish errors were trapped before closing the dialog.
 - They aren't, so...catch them downstream and reopen the dialog?
 - Oops, that didn't "work", so change something else, something
   that isn't broken and doesn't participate in the cause, but
   merely gets in the way of the palliative procedure.

No.

Instead: wx provides no particular guarantee of exception safety,
so it's my job to guard against an exception escaping. Thus, I
now believe I should put Run() inside a try-block, as you mention
in a paragraph I'll copy here from above...

>> Notice that an alternative could be to move Run() inside try/catch clause
>> instead but it seems inconsistent to catch only some exceptions and not all
>> of them, even if now (i.e. with my latest changes to wx) catching them or
>> letting them escape shouldn't change the observable behaviour.

...in order to say I believe wx actually can't guarantee that
observable behavior won't change. Either OnCreate() returns true,
or it returns false--with different behaviors--or else it throws,
in which case it can't conform to both of the different behaviors.
AIUI, you've changed the "throw" behavior so that it's as though
OnCreate() returned false, instead of true as before. IOW, this:
  File | New | Illustration
  [enter invalid input that will cause an exception to escape]
  OK
now results in the view window closing itself, instead of leaving
it open.

And I do not object to that change whatsoever. What I'm asserting
is that exceptions I throw are my responsibility, and I shouldn't
even hope that wx can magically do what I want when I throw one,
especially because I've had such a difficult time deciding what
I do want. AIUI, your wx change is a good idea nevertheless; but
no wx change can solve the whole lmi problem--I must solve that
in lmi. Right now, I think the best way is for lmi to trap all its
own exceptions in its overridden OnCreate(), and make its own
decisions about handling them. And the decision I'm leaning toward
is to preserve the observable behavior of the production system:
in the preceding paragraph's testcase, that is, to return 'true',
so that the user can either close the empty view, or edit the
input to make it valid. IOW, IllustrationView::OnCreate() should
return true iff a view was successfully created, because returning
anything else would be unnatural.