What data should be checked in methods?

Question

PHP

Colleagues, hello everyone.
I have been programming for a long time. I disassemble Kohana and Laravel by bones. I am well versed in engines, but I still can’t formulate certain postulates for myself, let’s say, regarding what data I can trust when creating methods in classes, what not, what I should check what is not.
For example. Kohan has a configuration file for the database. The file returns an array (key => value) in which, among other things, the name of the database itself is indicated. It is assumed that the programmer will write a string with the name of the database into this member. But! For example, we enter an array there. Well, that's it, an array and that's it.
We run the script, and when it comes to database queries, it becomes clear that the settings contain an incorrect value, but it manifests itself deep in the engine, directly when the mysql_select_db () function is executed. Those. developer Kohana took the settings file, split it into components and drove on without checking what values ​​are contained in the array. And when it came to the database selection command, our PHP threw an error.
Well, if an example is. But there are all sorts of tricky cases. If you don’t check something now, it may come out further somewhere in some way, somehow it’s not obvious.
Yes, I can check anything and everything today, but there are very few checks in Laravel. If I write classes with total checking, they will be like white crows among the classes of other programmers who did not bother with checking, but have clean code.
Colleagues, what is your strategy in this regard?

Answer 1

My principle is that such things should be checked by functional tests of the application, i.e. these are not the input data of the application, why bother checking them. And such errors of programmers should emerge at the stage of automatic testing of the program.

Answer 2

perhaps in the future type-hinting for scalars will be introduced .
There is a separate Symfony/config component that is responsible for validating settings. That is, each component describes all the settings it wants to receive, what data format is acceptable, default values, etc. The validation of all this and the assembly is handled by a separate component. Perhaps this is the reason why there are so few checks in the Laravel code, because all these checks were made in the earlier stages.
In fact, in frameworks using Dependency Injection, the approach with a separate component for parameter validation will be the most convenient. All validation logic and all boilerplate code are gone, while the code of the component itself remains clean. Thus, the need to validate input data remains only for public methods, and in some cases this can be neglected.