The mid-term plan is to replace these by properly named errors.
The name of the error can then be printed as part of the error message.
Expected benefits:
We can mechanically check whether each error has a trigger in the testsuite.
We can mechanically check whether each error is covered by the documentation.
We can have a wiki with a page for each error, with the error message linking to it (or we link to the docs). See: #659
Steps to implement:
Prevent new instances of Generic[Doc]Error in our code base, while working off the old ones. This could be ensured by a watchdog in the CI.
For each Generic[Doc]Error (see e.g. #7223):
Check for a reproducer in the test suite. Add one if missing.
Check if there exists a suitable named error yet that could cover that error message.
We have currently short of 250 places where we throw a
GenericError
orGenericDocError
.The mid-term plan is to replace these by properly named errors. The name of the error can then be printed as part of the error message. Expected benefits:
Steps to implement:
Generic[Doc]Error
in our code base, while working off the old ones. This could be ensured by a watchdog in the CI.Generic[Doc]Error
(see e.g. #7223):The current list of occurrences is (2024-04-15):
Suggested prioritization: