Earl Miles wrote:
> I think you are mistaken.
Could be. :)
I see where I went wrong. The 'unprivileged' user I was using to test
had read ability on the test database, so he was able to select the
database the first time. You're probably using one that has no
privileges for the database whatsoever.
I dunno. I still don't see that this is very common.
Maybe we should talk about making a v1.8, where we break the ABI in
several ways at once? Take a look at the current Wishlist. There are
several items there that qualify.
> The second would be to set a flag in the catch block, and once the catch
> block is exited, check that flag and execute the code that is currently
> in the catch block. Possibly a bit kludgy, but possibly safer than
> simply disabling exceptions entirely, depending on whether or not my
> concerns are valid.
Do you know anything about scoped locks? Something similar could be
used here. Make an interface class that has functions for temporarily
disabling exceptions; derive Connection from it. Make another class
that takes a reference to an object with this interface, and calls the
disable function. When the disabler object goes out of scope, it calls
the re-enable function.
I've got an item for something similar for the Connection class's lock()
mechanism. It should use scoped locks, instead of the mechanism it
currently does.
