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.
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.