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
