Ed Leafe wrote: > On Jun 19, 2007, at 2:34 AM, <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> wrote: > >> I found and read the coments on lockDisplay. Apparently the lock >> and unlock >> are a 1 to 1 relation, similar in functionality to the SQL Begin >> Trans/End >> Trans where the transactions is not actually "committed" (or in our >> case the >> display is actually not unfrozen) until the outermost call is >> completed and >> you cannot have more unlocks than locks. > > Exactly - it's a push/pop approach. Imagine if a routine locked the > display, and then called another routine that also locked/unlocked > the display. If all it took was a single unlock to undo all the > previous locks, you would have to be very careful to preserve the > state. This way, as long as you clean up after yourself by making > sure you unlock any lock you set, things will be fine. > > I've added some code to dPemMixin that will prevent exceptions like > you received from disrupting your program. Instead, the error is > logged and the program continues. And anticipating Paul's question > (<g>), yes, I think that this is preferable to the program crashing, > and too many unlocks are not fatal in nature, but should not be > ignored, either.
The problem I have with Dabo doing this is that it takes control away from the end-developer. I *want* exceptions to interrupt my program flow. They tend to tell me exactly what the problem is and exactly where it occurred, so I can research the problem and fix my code. When Dabo traps the exception and instead writes to the error log, we risk the messages not saying enough about where the error occurred to be able to figure out how to fix it. In the case of the unlockDisplay() throwing an exception, if the end-developer chooses that it isn't critical, IMO *they* should be in control to make the try/except block. 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. -- 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]
