How do you propose that the SQLite library code determine what errors the current user cares about?

Ha, I propose that it shouldn't! I never want SQLite to determine "what errors I should care about". Particularly in a case like this, where it will continue to function for every table, index, and non-broken view.

...alternatively, I propose that SQLite could fail sooner. The most confusing thing in this case was that the query was partially working.

1. I think the point is not whether or not report the error, it is how the error can be reported.

2. To me, throws an error arbitrary for such a function directly is not quite graceful. I say "such a function" I mean it could be used as a tool like SELECT * FROM pragma_table_info('x') to get info, and it is not uncommon to be put in a subquery or a join like in https://sqlite.org/pragma.html#pragfunc introduced. If user want the query run successfully without reporting a query error, user at least should check if a table that contained in a view x exists or not, check if a virtual module used by table x is valid or not, etc, this is not quite neat to me too. Sometimes pragma_table_info('x') is just act as a assistant tool in a subquery or a join, let it throws an query error to interrupt everything is too much for this kind of tool, sometimes user just don't care if it executed failed with some specific value (parameter), and want to just ignore it, to achieve the goal that the whole query exec successfully.

3. The UPDATE OR ABORT/FAIL/IGNORE/REPLACE/ROLLBACK ... statement is a work example that SQLite let user determine what errors user care about, or in other word, let user choose how user want to do if user met an error. And there're also many ways that let user know an error occurred without throwing a query failed error, like put the error info to query result field, however, I'm not suggesting this way, this is just an example to show possibility.

4. There're arguments about whether or not SQLite needs to supports stored procedures, like in thread https://sqlite.org/forum/forumpost/78a60bdeec7c1ee9, for me, stored procedures can at least can handle the situation in #2 "If user want this query run successfully without reporting an error, user at least should check if a table that contained in a view x exists or not..." more cleaner around current error reporting logic.

RE: Your point #1, "how the error can be reported"

I forgot to mention that I ran "PRAGMA integrity_check;" and got "ok". If a broken view is going to create errors downstream, maybe integrity_check should be reporting that? Or even better, add broken view checking to "PRAGMA quick_check;" (because the full integrity_check takes a long time).