> > But, the issue is, I have many places where I write to the database and
> > would have to embed each of these in a try/except block. I can do that,
> > but wondered if there is a "global" way to catch this 'database is locked'
> > error? I found someone asking this sort of question online but it doesn't
> > appear to be answered:
> > http://bytes.com/topic/python/answers/799486-how-do-i-prevent-exceptions-stopping-execution-global-exception-handler
>
> I'm not sure why you would like to do that: your code assumes the database
> interaction works fine, and based on that just continues it's normal flow. If
> the database is locked, you'll need to do something to prevent your code
> crashing further down, which is what you put in the except OperationalError:
> block. I would assume that the error handling depends on where you are in the
> code.
> If you can always perform the same type of error handling, just create a
> convenience function (possibly with the SQL statement as argument) that calls
> the database and returns the results, and put the database call inside the
> try: except: clause. Then you need to do this only once.
Interesting, it didn't occur to me to do that. I may give it a try. Since I
am making INSERTs and UPDATEs to the database from all over the application (in
different modules), maybe I should put this error-handling convenience function
in a module and import it into every other module, then I can just use it.
Unfortunately, I'll still have to go back and find every instance of when I do
INSERT or UPDATE to change this to use the convenience function, but it will
still save me some keystrokes to fix the app.
> A global way to catch the database-locked exception is just to put the try:
> except OperationalError: around your complete code. Exceptions propagate all
> the way to the function where your program started, and if you catch it
> there, you will catch every OperationalError exception from anywhere in the
> code. Of course, your program then always exits anyway, because you can't
> return to the point where the the exception was thrown (or maybe you can, but
> not that I'm aware of. I wouldn't recommend it though).
That I really didn't know at all. But yes, if the program exits, that's not
going to work.
> > > p.s. *I use the nice program SQLite Database Browser and if I edit a
> > > field in the database my Python app is accessing, click "Apply changes",
> > > but I do *not* save the changes (that is, I do not click the disk icon),
> > > when I go to write to that database from my Python app, I get a 'database
> > > is locked' error.
> Sounds like somewhat odd behaviour to me: "apply changes" for me means "apply
> & commit", ie, it includes the save operation. Might
> just be me. I guess "Apply changes" opens the database connection, but then
> "save" performs the actual commit to the database, and
> in the meantime the database is locked.
I don't know, either, but I was glad to find a way to reproduce the problem so
that I could anticipate it for potential users.
Thanks for your help,
Che
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
