Should we use “assert()”?

  • This topic has 6 replies, 1 voice, and was last updated 23 seconds ago by exakat.
Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #2709

    I have a [pet project]( which is supposed to act as a set of helper functions for different things.

    Due to its nature, it has to make some validations before executing the code.

    Since it’s a utility lib I wanted to make it as fast as possible (spoiler: it’s not). My idea was to use `assert()` as a validator function.

    Depending on [settings]( the `assert()` can be skipped, or even removed from parsing. My idea is that on development env the `assert()` would be used to indicate the developer that there are some errors, yet on production env those checks would be disabled.

    And then it hit me – I’ve never had to change this setting. I’ve probably never bothered about this at all.

    So the question – is it _wise_ to use `assert()`, or should I replace it with the normal check and `InvalidArgumentException`?



    In PHP 5 it was almost entirely useless. In PHP 7 it became useful but you had to adjust INI settings, which means libraries couldn’t rely on it but applications could. In both PHP 5 and 7 the default was to emit a warning and then continue. That’s not a great experience.

    So I changed the default assertion failure mode to throw for PHP 8. I now encourage libraries or apps explicitly supporting PHP 8 to use asserts, with a caveat: I don’t recommend changing the exception type. And of course, normal assertion recommendations apply: don’t include anything with side effects in the assertion and so on.


    Assert with whatever you want – the WebMozart Assert library is very good, for example.

    If you do use `assert()`, [leave them turned on in production](


    IMO there’s not a correct answer to this, simply trade-offs.

    Given the nature of the library, I’d expect it caters to more experienced users. They’d tend to do more thorough testing during development, so assertions that are skipped in prod may be plenty.

    Outside of tests, I usually limit `assert` to checks that can’t be (easily) expressed through the type system – nonempty arrays, things that would be generics, etc. They work well alongside static analysis tools like PHPStan.

    Really depends how thorough and accurate your tests and types are. In a legacy system that’s been cobbled together, you’d probably want checks that can’t be disabled at runtime.


    `assert` is not for input validation. It’s for conditions that are supposed to be _impossible_ to fail.


    I often use assert where I would otherwise use `/** @var Thing $thing */` and so on. E.g. “stupid checks” that hardly relate to business logic. Hasn’t hurt me yet.


    PHP assertions and their usage


Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.