In the old core, API tried to guess for a user/developer, overlook errors and inaccuracies. As a result, errors that are difficult to catch may occur. In addition, such an approach causes a lot of implicit agreements that must be taken into account.
For example, a user/developer selects entries for deletion using a filter. In this case, they incidentally make a writing error in the filter name. A typical API of the old core will ignore this filter and return all the entries. The next instruction will successfully delete all of these entries.
The method changes in the new core. API does not have to guess anything for a user. API must respond appropriately if it meets an unexpected situation, such as an unknown filter, no id transmitted, lack of value, excessive value, must not be invoked in this mode, etc.
When an error is displayed on the screen (if the debugging mode is available), the
/error.php file is included. You can print error in the site design inside this file, as well as specify HTTP status code (for example, "500 Internal Server Error").