Opened 17 years ago
Closed 13 years ago
#6928 closed Uncategorized (fixed)
commit_on_success: Handle KeyboardInterrupt
Reported by: | Thomas Güttler | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Since Python 2.5 KeyboardInterrupt does not inherit from Exception, but
from BaseException. If there is a bug in a method which uses commit_on_success
and you hit ctrl-c on the shell, you don't see the real traceback, but
only this:
Traceback (most recent call last): File "/localhome/modw/listen/bin/index.py", line 148, in <module> main() File "/localhome/modw/listen/bin/index.py", line 68, in main index(file, ignore_mtime=ignore_mtime) File "/localhome/modw/listen/bin/index.py", line 78, in index index_file(file, ignore_mtime=ignore_mtime) File "/localhome/modw/modwork_esg/django/db/transaction.py", line 204, in _commit_on_success leave_transaction_management() File "/localhome/modw/modwork_esg/django/db/transaction.py", line 70, in leave_transaction_management raise TransactionManagementError("Transaction managed block ended with pending COMMIT/ROLLBACK") django.db.transaction.TransactionManagementError: Transaction managed block ended with pending COMMIT/ROLLBACK
This small patch handles KeyboardInterrupt in commit_on_success() better.
Python Docu for KeyboardInterrupt: http://docs.python.org/lib/module-exceptions.html#l2h-111
Attachments (1)
Change History (9)
by , 17 years ago
comment:1 by , 17 years ago
Triage Stage: | Unreviewed → Accepted |
---|
Is there any reason to check KeyboardInterrupt instead of BaseException?
comment:2 by , 17 years ago
I didn't use BaseException since it was introduced in Python 2.5. Django tries to support Python 2.3.
Thank you for looking at this patch.
comment:3 by , 17 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Thanks for the explanation ;)
comment:4 by , 16 years ago
I'm going to through SystemExit in there as well, for all the same reasons, I think. No need to treat that specially in that particular case (although it may well fail anyway for other reasons).
comment:5 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:6 by , 16 years ago
Cc: | removed |
---|
comment:7 by , 13 years ago
Easy pickings: | unset |
---|---|
Resolution: | fixed |
Severity: | → Normal |
Status: | closed → reopened |
Type: | → Uncategorized |
UI/UX: | unset |
after [14288] transaction.commit_on_success does not handle KeyboardInterrupt
.
Problem in django.db.transaction.Transaction.__exit__
and default exiting
function.
def __exit__(self, exc_type, exc_value, traceback): self.exiting(exc_value, self.using)
exc_value
is None after KeybordInterrupt
has been throwed, only exc_type
and traceback
has value.
But if raise KeybordInterrupt
manualy from code it's work ok.
Possible solution: use exc_type
and exc_value
in exiting
function
I use python 2.6.6
comment:8 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
The issue in this ticket was closed long ago. The new comment refers to a new issue, so I have created ticket #16682 for that. Closing this again.
Handle KeyboardInterrupt.