Hi,
The documentation of assert (https://php.net/assert)) states that's debugging only. This is further enforced by php.ini flags to disable assertions in production.
Why are the use cases of this feature being limited to debugging? We can see from the popularity of user-space assertion libraries, like webmozart/asset and beberlei/assert, that there is a need for runtime assertions.
Arnold Daniels - Chat @ Spike [yux2k]
2021-04-01 10:24 GMT+02:00, Arnold Daniels arnold.adaniels.nl@gmail.com:
Hi,
The documentation of
assert
(https://php.net/assert))
states that's debugging only. This is further enforced by php.ini flags to
disable assertions in production.Why are the use cases of this feature being limited to debugging? We can see
from the popularity of user-space assertion libraries, like
webmozart/asset and
beberlei/assert, that
there is a need for runtime assertions.Arnold Daniels - Chat @
Spike [yux2k]
Dunno about the motivation of the implementors, but usually assertions
are used for internal invariants and mental checks while exceptions
should be used for interaction with the outside world (database
errors, user input errors etc). If you follow this, an assert error
will never be useful for a user, it will always be an "internal
error", and that's why it can (should?) be disabled in production.
Olle
On Thu, Apr 1, 2021 at 10:50 AM Olle Härstedt olleharstedt@gmail.com
wrote:
2021-04-01 10:24 GMT+02:00, Arnold Daniels arnold.adaniels.nl@gmail.com:
Hi,
The documentation of
assert
(
https://php.net/assert))
states that's debugging only. This is further enforced by php.ini flags
to
disable assertions in production.Why are the use cases of this feature being limited to debugging? We can
see
from the popularity of user-space assertion libraries, like
webmozart/asset and
beberlei/assert, that
there is a need for runtime assertions.Arnold Daniels - Chat @
Spike
[yux2k]Dunno about the motivation of the implementors, but usually assertions
are used for internal invariants and mental checks while exceptions
should be used for interaction with the outside world (database
errors, user input errors etc). If you follow this, an assert error
will never be useful for a user, it will always be an "internal
error", and that's why it can (should?) be disabled in production.Olle
--
To unsubscribe, visit: https://www.php.net/unsub.php
Hi,
I agree with Olle's explanation (and am indeed using assert() that way).
Also note that both linked libs throw InvalidArgumentException
(subclasses of), so not the same kind of "assertions" (despite the name).
Regards,
--
Guilliam Xavier
Le 01/04/2021 à 10:50, Olle Härstedt a écrit :
Dunno about the motivation of the implementors, but usually assertions
are used for internal invariants and mental checks while exceptions
should be used for interaction with the outside world (database
errors, user input errors etc). If you follow this, an assert error
will never be useful for a user, it will always be an "internal
error", and that's why it can (should?) be disabled in production.Olle
Hello,
I don't know about the original motivations either, but at work we
mostly use to force IDEs to understand types where PHP can't enforce
them, due to its highly dynamic nature and lacks of generics. Most of
our assert usage as like this: \asset($foo instanceof Bar);
We never enable those on production, we have assert() calls pretty much
everywhere and they don't serve any other purpose than being explicit
for the code readers and IDE and we use them for debugging purpose: it
raises exceptions for developer preventing them to proceed further until
they fixe the bugs, but they don't break the production.
Regards,
--
Pierre
Hi,
The documentation of
assert
(https://php.net/assert))
states that's debugging only. This is further enforced by php.ini flags
to disable assertions in production.
This is, in a sense, looking at things the wrong way around: the main feature of the built-in assert() statement is that it can be disabled in production, and the assertion code will not run at all. That feature is useful if you want to write assertions that run in development but have zero performance cost in production.
If you leave them switched on permanently, the advantage of using the built-in assert() over writing your own becomes very small - the definition would be two simple lines of code. There's nothing to stop you doing that, though; the documentation is just giving advice.
The two libraries you linked to concentrate on a very different feature: concisely writing certain common conditions, such as type and range checks. It might seem reasonable to include common features like this in the language, but the fact that you linked two different libraries demonstrates why that might not be a good idea: the API and feature set are hard to get right. Once a feature is added to the language it is very difficult to change.
Regards,
--
Rowan Tommins
[IMSoP]