Understanding the “never” Type in PHP

September 24, 2025

Alina Orel

When writing PHP functions, there are cases where you know a function will never return a value. This might happen because it always throws an exception, or it immediately calls exit or die. In PHP 8.1, the never type was introduced precisely for this scenario.

While you won’t use never every day, it’s a valuable tool for making your intent explicit to both PHP and other developers: this function does not return under any circumstances.

In this article, we’ll walk through what the never type is, how to use it, and common pitfalls. At the end, you’ll also find a quick reference cheat sheet.

☛ What Is never?
  • Introduced in PHP 8.1 (November 2021).
  • Used only as a return type.
  • Tells PHP that the function will not return a value at all.
  • Typical scenarios:
    • Throwing an exception.
    • Terminating script execution with exit() or die().

For example:

Here, doSomething() is guaranteed to throw an exception every time. PHP enforces this.

☛ What Happens If You Break the Rules?

If you try to return a value from a never function, PHP throws a fatal error:

Error:

Likewise, an implicit return (just letting the function end normally) will also break:

Error message:

☛ Restrictions of never

The never type has strict limitations:

Allowed only as a standalone return type.

Cannot be a parameter type.

Cannot be combined in intersection types.

Cannot be part of a union type.

☛ Real-World Example: dd() in Symfony

If you’ve used Laravel or Symfony, you know dd() (dump and die). It prints variables and then stops execution. The implementation in symfony/var-dumper uses never:

☛ Quick Reference Cheat Sheet

Introduced in PHP 8.1

Only used as a return type

Means the function never returns

Not allowed as parameter type

Not allowed in union or intersection types

Commonly used for functions that throw exceptions or terminate script execution

The never type is a small but powerful addition to PHP. It makes your intent explicit, improves code readability, and prevents subtle errors where a function might mistakenly return.

You’ll rarely need it — but when you do, it’s the cleanest way to communicate that a function always ends abnormally.