On 6/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Now that I know how it work, I like the current functionality. My goal was > to minimize screen "flashes" as the system updates info, which actually > really slows down system responsiveness. I don't want to unFreeze until the > top most unFreeze is fired. > > I agree with Nate in that it would be great if we could turn off the dabo > trapping so we can see the original cause of an exception.
I just like the idea because with the exceptions that are fired I know there is an error and exactly where it is. > > Larry Long > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Nate Lowrie > Sent: Tuesday, June 19, 2007 12:55 PM > To: Dabo Users list > Subject: Re: [dabo-users] Lockdisplay > > On 6/19/07, Ed Leafe <[EMAIL PROTECTED]> wrote: > > On Jun 19, 2007, at 12:21 PM, Paul McNett wrote: > > > > > But, I also recognize that, as an overarching framework, we can also > > > make our user/developer lives easier by trapping and handling > > > exceptions where we know how the person would want to handle it. The > > > problem is, this is a fuzzy line and everyones fuzz is different. > > > > > > So, I'm not really pushing for anything different right now, but > > > perhaps I'm starting to think about ways to have our cake and eat it > > > too. A dabo.settings.trap_exceptions flag could work... > > > > > > As a developer of Dabo, I personally get quite annoyed every time I > > > need to track down a QueryException raised my my bizobj, which could > > > have started out as a python TypeError buried way down in some > > > obscure dCursorMixin method. If we had just let the original > > > exception propagate, instead of trapping it and changing it, the > > > debug cycle wouldn't be so convoluted. > > > > That's a good example where silently trapping an error causes > > more harm than good. Those should obviously not be silenced. > > > > I draw a distinction between errors that are the result of > > something done wrong, and errors that are the result of arbitrary > > design decisions. In the case of wxPython's Freeze/Thaw > > implementation, there is no reason why calling Thaw() should ever > > throw an error. I actually first implemented this as a DisplayLocked > > property, but changed to the stacked method call implementation > > instead. But had I done it as a property, would you expect this to throw > an error? > > I am with Paul on this. I would prefer an error. In the code you described > below might not need an error, but the runtime logic the developer wants is > wrong anyway. As a developer, I want the error thrown so I don't have to > track down the obscure behavior from a runtime error. > > Maybe the solution is to add a catch errors property/attribute to either > dabo or dApp that will catch or not catch errors. That way people can > develop like they prefer. > > > > > self.DisplayLocked = False > > ...code... > > self.DisplayLocked = False > > > > This is doing exactly the same thing as calling > > unlockDisplay() twice without ever calling lockDisplay(). IOW, this is > > an artifact of the implementation, and is not a logic error. > > > > -- Ed Leafe > > -- http://leafe.com > > -- http://dabodev.com > > > > > > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
