Ed Leafe wrote: > On Jun 25, 2008, at 2:59 PM, Nate Lowrie wrote: > >> Did the testing. The problem was in this case that self referred to >> the dTextBox object rather than the form. Because of the try/except >> clause around the eval statement (line 383), the error was silent and >> not reported. When I replaced the component with >> 'self.Form._myBizobj' it work, though I found out that the >> _scrIsBizobj parameter wasn't being set properly if the string did >> turn out to be a Bizobj. Fixed both in the latest commit. > > > OK, I'll integrate that with the changes I've been making. I've been > trying to methodically go through the whole framework and remove every > bare 'except:' in the code, since these seem to be masking a small but > significant number of issues. > > I hereby propose that a new coding standard be adopted in Dabo: no > bare except: statements allowed. Evert try has to catch specific > exceptions, or, if the potential exception is unknown (such as when > replacing them in very old code), the except catches StandardError and > writes it to dabo.errorLog. > > Paul, any feelings on this?
Bare excepts are evil. Not letting unhandled exceptions propagate are evil. However, there could be limited use for them. But those uses would likely be in the tools (report writer to catch errors in the field expressions, for example) instead of the base framework. The error log should only be for things we expect, not which we don't expect. Unexpected things should *always* be re-raised. The dBizobj standard of catching certain exceptions and re-raising them as dbException is evil, as it masks the original bug inside the framework. So yeah, I have feelings on this. :) Paul _______________________________________________ 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/[EMAIL PROTECTED]
