Ed Leafe wrote: > On Jun 19, 2007, at 12:55 PM, Nate Lowrie wrote: > >> 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. > > Do you mean just for this particular example, or for all cases? IOW, > if any code attempts to set a property to a value it already is set > to, that should throw an error? That was my point in illustrating > that repetitive calls to unlockDisplay() are conceptually no > different than setting a DisplayLocked property to False when it > already was False. The developer should *know* that it is already > False, so any code that tries to set it to the same value *must* be a > bug. The developer should be smart enough to write: > > if self.DisplayLocked: > self.DisplayLocked = False > > to avoid any problems, right?
Just so we are clear, I agree with Ed about the lockDisplay() case. My original response was to carry on with the discussion of this exception-raising in general. The problem with the global setting to catch or not catch is that we'll have to block code everywhere based on that setting. So again, my only intent was to raise the issue, not push for anything different. -- pkm ~ http://paulmcnett.com _______________________________________________ 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]
