Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123291
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
Subject: Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a
 standard function
In-Reply-To: <GUMp_LJKefk4aLz9P9MA-zonKuik6uUNWZTtOAx-IeIhjPFsgfT3HHECPpyGF_ujq-LxI6tzBxMYgL5CMVGRkyzxSugweKix_YUGo2rXnb4=@gpb.moe>
Date: Fri, 10 May 2024 00:18:33 +0900
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <CCE326F2-8D39-47C7-A8BB-17F78FA0EE8D@sakiot.com>
References: <GUMp_LJKefk4aLz9P9MA-zonKuik6uUNWZTtOAx-IeIhjPFsgfT3HHECPpyGF_ujq-LxI6tzBxMYgL5CMVGRkyzxSugweKix_YUGo2rXnb4=@gpb.moe>
To: "Gina P. Banyard" <internals@gpb.moe>
From: saki@sakiot.com (Saki Takamachi)

Hi Gina,

> Hello Internals,
>=20
> I would like to formally propose my idea for exit() as a function =
brought up to the list on 2024-02-24 [1] with the following RFC:
> https://wiki.php.net/rfc/exit-as-function
>=20
> There have been some slight tweaks to the implementation, namely that =
the transformation from a "constant" to a function is done at compile =
time and we do not hook into the behaviour of constants any longer.
>=20
> Let me know what you think.
>=20
> Best regards,
>=20
> Gina P. Banyard
>=20
> [1] https://externals.io/message/122483

I generally agree :)

My only concern is that if this function throws an error and I catch it, =
won't it proceed against the user's intentions about it. I am concerned =
that this may lead to data corruption and personal information leaks due =
to unintentional data being inserted into the DB.

```
try {
    exit([]);
} catch (Throwable) {
    //
}
```

Probably no one likes to write code like this, and even if there are, =
there are probably very few, but code that is written with the =
assumption that exit will always stop processing may be a little =
dangerous.

Is it nonsense to always stop processing even if an error occurs? Or, =
how about creating an uncatchable exception class specifically for =
exits? Or is this level of risk negligible?

I am writing down the ideas I came up with, so please excuse me if there =
are any mistakes in my understanding.

Regard,

Saki=