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]
