Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make VFS use chained exceptions #489

Closed
4 tasks done
rogerbinns opened this issue Sep 28, 2023 · 2 comments
Closed
4 tasks done

Make VFS use chained exceptions #489

rogerbinns opened this issue Sep 28, 2023 · 2 comments

Comments

@rogerbinns
Copy link
Owner

rogerbinns commented Sep 28, 2023

APSW has avoided chained exceptions with VFS in the past because they didn't exist under Python 2, and because it muddies the waters. For example a VFS exception could cause SQLite to take recovery actions which could then result in further completely unrelated exceptions, so the chaining didn't make semantic sense. SQLite is also running an error code system which Python exceptions hide.

But using unraiseable also results in the exceptions being cleared after printing, so it gets more difficult to tie exceptions that happened around each other together. Doing testing of pathological error conditions has shown that chaining is the better way of handling this.

It will result in observable different behaviour in the release including this, but only when exceptions happen and even then mostly when more than one exception happens during the same SQLite call. Far more exceptions that previously came through via the unraisable mechanism will now come through directly.

  • Update VFS pre/post amble
  • Update test suite
  • Update vfs docs about exceptions, changing, unraisable etc
  • Better detection the vfs is one of ours (xAccess is currently used but could be omitted)
@rogerbinns
Copy link
Owner Author

An example of unexpected behaviour is that SQLite calls xDlOpen a second time (with slightly different parameters) if the first call returns NULL. Consequently you will the first call exception chained to the second call exception.

@rogerbinns
Copy link
Owner Author

3d117db is the final commit addressing this issue and it is now merged into master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant