Throw exceptions on SQL errors

[cedric-anne]

Checklist before requesting a review

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works.
• This change requires a documentation update.

Description

Since we did not have a centralized error catching in the past, we were not able to throw exceptions when a SQL error occurred. They were just logged and were not stopping the code execution, and this could have the effect of triggering hard-to-debug errors in subsequently executed code.

Now we have a centralized error catching system, we can throw exceptions when a SQL error is triggered. It would result in displaying the error page. For instance, if I force a SQL querry error in the impact analysis tab:

[cedric-anne]

E2E tests are failing due to the SQL error reported in #18175.

[AdrienClairembault]

With these changes, should Toolbox::logSqlError() and the associated sql-errors.log file be depreciated/removed ?

With the new exception, SQL errors end up directly in the php-errors-log file.
I don't see a use case for manually calling Toolbox::logSqlError().

[cedric-anne]

With these changes, should Toolbox::logSqlError() and the associated sql-errors.log file be depreciated/removed ?

With the new exception, SQL errors end up directly in the php-errors-log file. I don't see a use case for manually calling Toolbox::logSqlError().

sql-errors.log still contains SQL warnings and SQL debug info. We could change it, but it is out of the scope of the current PR.

[trasher]

Any reason this one is still draft, or should me merge (e2e error is not a blocker)?

[cedric-anne]

Any reason this one is still draft, or should me merge (e2e error is not a blocker)?

The e2e tests fails due to an SQL error that is now blocking, see #18175. We have to fix this SQL error before being able to merge the current PR.

[cedric-anne]

I added a commit to quickly adapt the install/update process.