Everything

php

Why is assert limited to a debugging feature only?

php.internals

Arnold Daniels

5 years ago

Hi,

The documentation of `assert` ([https://php.net/assert)](https://www.php.net/manual/en/function.assert.php)) 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](https://packagist.org/packages/webmozart/assert) and [beberlei/assert](https://packagist.org/packages/beberlei/assert), that there is a need for runtime assertions.

[Arnold Daniels - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=yux2k)	[yux2k]

Olle Härstedt

5 years ago

2021-04-01 10:24 GMT+02:00, Arnold Daniels <arnold.adaniels.nl@gmail.com>:

> Hi,
>
> The documentation of `assert`
> ([https://php.net/assert)](https://www.php.net/manual/en/function.assert.php))
> 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](https://packagist.org/packages/webmozart/assert) and
> [beberlei/assert](https://packagist.org/packages/beberlei/assert), that
> there is a need for runtime assertions.
>
> [Arnold Daniels - Chat @
> Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=yux2k)	[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

Guilliam Xavier

5 years ago

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)](https://www.php.net/manual/en/function.assert.php
> ))
> > 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](https://packagist.org/packages/webmozart/assert) and
> > [beberlei/assert](https://packagist.org/packages/beberlei/assert), that
> > there is a need for runtime assertions.
> >
> > [Arnold Daniels - Chat @
> > Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=yux2k)
>      [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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> 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

Pierre

5 years ago

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

Rowan Collins

5 years ago

Hi,

On 1 April 2021 09:24:54 BST, Arnold Daniels <arnold.adaniels.nl@gmail.com> wrote:

>The documentation of `assert`
>([https://php.net/assert)](https://www.php.net/manual/en/function.assert.php))
>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]