Re: [RFC] Transform exit() from a language construct into a standard function

From: Date: Sat, 11 May 2024 14:45:44 +0000
Subject: Re: [RFC] Transform exit() from a language construct into a standard function
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-123311@lists.php.net to get a copy of this message
On Thursday, 9 May 2024 at 16:18, Saki Takamachi <saki@sakiot.com> wrote: > Hi Gina, > > > Hello Internals, > > > > 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 > > > > 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. > > > > Let me know what you think. > > > > Best regards, > > > > Gina P. Banyard > > > > [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 You can already escape an exit() call, either by setting an error handler that throws, or by passing a non-stringable object. See: https://3v4l.org/vR3up Best regards, Gina P. Banyard

« previous php.internals (#123311) next »