> What I want: throw an error when corruption is detected and let the code handle it.

I wonder what that code would look like. My sense is that it’ll look exactly like the code that would run as if the transactions never occurred to begin with, which is why the SQLite design makes sense.

For example, I have a database of todos that sync locally from the cloud. The WAL gets corrupted. The WAL gets truncated the next time the DB is opened. The app logic then checks the last update timestamp in the DB and syncs with the cloud.

I don’t see what the app would do differently if it were notified about the WAL corruption.

Exactly. I'd read it as

> I want to correct errors that the DB wizard who implemented SQLite chose not to

When there's a design decision in such a high profile project that you disagree with, it's either

1. You don't understand why it was done like this.

2. You can (and probably will) submit a change that would solve it.

If you find yourself in the situation of understanding, yet not doing anything about it, you're the Schrodinger's developer: you're right and wrong until you collapse the mouth function by putting money on it.

It's very rarely an easy to fix mistake.