Assertions can generate warnings

[BackEndTea]

Some assertions call functions that may generate a warning if called with incorrect parameters, e.g. preg_match, strlen.

It would be better if they do not generate a warning when called, but either pass the assertion, or throw the exception.

This can be solved in one of two ways:

• Silence errors using @ where possible
• Assert the input is of the correct type, and throw an exception when it is not.

The issue with the second type is that it is a theoretical BC break. For example, the user may input an object that can be cast to a string, in which case most functions will do so, in which case it may pass the assertion.

Silencing the errors will however not save us from the TypeErrors that php 8.0 will start throwing: https://wiki.php.net/rfc/consistent_type_errors.

There is also the current issue of all the count related assertions, which do not check if the passed value is countable. So before php 7.2 everything is fine, but after that an warning is generated.

Personally i'm fine with the theoretical BC break, as it isn't really intended behaviour, as it is dependent on the implementation.

[zerkms]

The second path should not be a BC: if input was so wrong that it throws a php warning - then the assertion should have failed as well.