I suppose we could split error_handler into two additional more specialised functions. For example:
validation_error_handler (crappy -- too verbose -- name) exception_handler while still retaining error_handler as a composition of both. Simon Kevin Dangoor wrote: > There's something about that that still bothers me. I can imagine many > circumstances under which a method is equipped to handle validation, > but not unusual exceptions. In fact, I think that will be the common > case. I think we need to tweak the behavior a little to fit the common > case, but I'm not completely certain what the tweak should be. > > Kevin > > On 2/9/06, Simon Belak <[EMAIL PROTECTED]> wrote: >> By declaring tg_errors parameter you are also declaring method to be >> it's own error handler (for cases where no more specific hook exists). >> Consequently when the exception gets raised, create is called with >> exception as tg_errors. Upon second raise from within create, control is >> passed to a lower layer (CherryPy) to prevent infinite loops. >> >> As I have said in my previous response, best idiom would be to use >> specialisation. >> >> >> Simon >> >> Randall wrote: >>> Here's a clear example of the strange behaviour I'm observing. >>> >>> @turbogears.expose() >>> def add(self): >>> # The exception is being thrown during the next statement. >>> self.form_widget = createReviewerForm() >>> return DataController.add(self) >>> >>> @turbogears.expose() >>> @turbogears.validate(form=createReviewerForm) >>> def create(self, reviewer, writer, permission, tg_errors=None): >>> if tg_errors: >>> print tg_errors >>> self.add() >>> data = dict(reviewer=reviewer, writer=writer, >>> permission=permission) >>> try: >>> # Should throw an exception because of a unique constraint. >>> DataController.create(self, **data) >>> except Exception, e: >>> print e >>> # Please raise this exception. >>> raise >>> >>> I would expect this when create is called: >>> ERROR: duplicate key violates unique constraint >>> "reviewer_association_ui" >>> Which I saw in standard output because of "print e". >>> >>> But instead TG raised this: >>> ERROR: current transaction is aborted, commands ignored until end >>> of transaction block >>> >>> The only thing I can figure is that TG is calling the create method >>> twice. If that's the case, why? Why doesn't TG just throw the >>> exception when it runs into it? >>> >>> Randall >>> >>> > > > -- > Kevin Dangoor > Author of the Zesty News RSS newsreader > > email: [EMAIL PROTECTED] > company: http://www.BlazingThings.com > blog: http://www.BlueSkyOnMars.com > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
