Le dimanche 10 février 2019, 09:34:16 CET Pierre Joye a écrit :
> However I think you are right as well in your other replies. While I wrote
> @ free code since years and I rarely see some in modern code, removing it
> may bring some BC issues that could delay 8 adoptions.
Not sure where in this
HI Stas,
On Sun, Feb 10, 2019, 8:17 AM Stanislav Malyshev Hi!
>
> > My thought that @ mainly relates to another RFC where errors/warning
> > are very inconsistently reported or designed (like forcing one to use
> > @). 8 would be a good candidate to clean that up, like the TypeError
> > RFC.
>
>
Hi!
> My thought that @ mainly relates to another RFC where errors/warning
> are very inconsistently reported or designed (like forcing one to use
> @). 8 would be a good candidate to clean that up, like the TypeError
> RFC.
Cleaning up how PHP does errors would be awesome. After 20+ years of
Hi!
> I am surely missing use cases because I wonder why we need @, at all?
Many functions have to deal with "dirty" data - e.g. loading a file that
is supposed to be JSON but may be in fact be invalid in any of the
hundreds ways. In some cases, we want full diagnostics, in other cases,
just
Am 07.02.2019 um 14:28 schrieb Rowan Collins :
> On 7 February 2019 11:19:46 GMT+00:00, Benjamin Morel
> wrote:
>> Also, some applications might assume that the directory does not already
>> exist, and want to fail if it does. So both use cases must be available in
>> the API.
mkdir("foo") or
On 7 February 2019 11:19:46 GMT+00:00, Benjamin Morel
wrote:
>Also, some applications might assume that the directory does not
>already
>exist, and want to fail if it does. So both use cases must be available
>in
>the API.
I absolutely agree, but I also agree that the task here is not "convert
>
> Please don't do that either, I don't want to convert
> @mkdir("foo");
> to
> try { mkdir("foo"); } catch (Exception $e) {}
> just to stop my script from exiting if the directory already exists.
What you really want is either another function that does not throw an
exception
Am 07.02.2019 um 10:01 schrieb Benjamin Morel :
> IMO, @ can be safely removed the day PHP converts current warnings to
> exceptions.
Please don't do that either, I don't want to convert
@mkdir("foo");
to
try { mkdir("foo"); } catch (Exception $e) {}
just to stop my script from
>
> That is one the cases I meant. Also this is a bug in the user code. I can
> imagine doing it on purpose for performance reasons (if the file is
> created/deleted by other apps) tho'.
> flock is what should be used here.
flock doesn't protect from other failures, such as a fread()ing a file
On Thu, Feb 7, 2019 at 3:14 PM Christian Schneider
wrote:
>
> Am 07.02.2019 um 02:32 schrieb Pierre Joye :
> > On Thu, Feb 7, 2019, 8:07 AM Girgias >> The most common case which comes to mind is to suppress erros while file
> >> reading.
> >> Because even if you check a file exists it could be
Am 07.02.2019 um 02:32 schrieb Pierre Joye :
> On Thu, Feb 7, 2019, 8:07 AM Girgias > The most common case which comes to mind is to suppress erros while file
>> reading.
>> Because even if you check a file exists it could be deleted inbetween the
>> check and the
>> read command. As you can see
On Thu, Feb 7, 2019, 8:07 AM Girgias
> The most common case which comes to mind is to suppress erros while file
> reading.
> Because even if you check a file exists it could be deleted inbetween the
> check and the
> read command. As you can see this is even written in the documentation [1]
>
>
On Thu, Feb 7, 2019 at 10:07 AM Girgias wrote:
> On Thu, 7 Feb 2019 at 02:03, Pierre Joye wrote:
>
> > Good morning Nikita,
> >
> > On Tue, Nov 27, 2018, 4:43 AM Nikita Popov >
> > > Hi internals,
> > >
> > > When the silencing operator @ is used, the intention is generally to
> > > silence
On Thu, 7 Feb 2019 at 02:03, Pierre Joye wrote:
> Good morning Nikita,
>
> On Tue, Nov 27, 2018, 4:43 AM Nikita Popov
> > Hi internals,
> >
> > When the silencing operator @ is used, the intention is generally to
> > silence expected warnings or notices. However, it currently also silences
> >
Good morning Nikita,
On Tue, Nov 27, 2018, 4:43 AM Nikita Popov Hi internals,
>
> When the silencing operator @ is used, the intention is generally to
> silence expected warnings or notices. However, it currently also silences
> fatal errors. As fatal errors also abort request execution, the
I don't really know if it fits here but some weeks ago I was thinking about
annotations with "@" prefix
and was considering to propose to handle @ (silence operator) similar way
as annotations, like:
$value = @ fopen('test.txt','rb+');
might be equivalent to:
$value = @SupressError(E_ALL)
Breaking BC might be unnecessary if instead of changing the default
behavior of @, you add an additional flag to error_reporting that
enables the new behavior, something like E_UNSILENCE_FATAL. Then
developers would only need to switch a flag in php.ini to get the old
behavior back, instead of
> Le 26 nov. 2018 à 22:42, Nikita Popov a écrit :
>
> Hi internals,
>
> When the silencing operator @ is used, the intention is generally to
> silence expected warnings or notices. However, it currently also silences
> fatal errors. As fatal errors also abort request execution, the result
On Mon, Nov 26, 2018 at 6:43 PM Nikita Popov wrote:
> Hi internals,
>
> When the silencing operator @ is used, the intention is generally to
> silence expected warnings or notices. However, it currently also silences
> fatal errors. As fatal errors also abort request execution, the result will
On 11/27/2018 8:26 AM, Nikita Popov wrote:
On Tue, Nov 27, 2018 at 2:20 PM Thomas Hruska
wrote:
On 11/26/2018 2:42 PM, Nikita Popov wrote:
Hi internals,
When the silencing operator @ is used, the intention is generally to
silence expected warnings or notices. However, it currently also
On Tue, Nov 27, 2018 at 2:20 PM Thomas Hruska
wrote:
> On 11/26/2018 2:42 PM, Nikita Popov wrote:
> > Hi internals,
> >
> > When the silencing operator @ is used, the intention is generally to
> > silence expected warnings or notices. However, it currently also silences
> > fatal errors. As
On 11/26/2018 2:42 PM, Nikita Popov wrote:
Hi internals,
When the silencing operator @ is used, the intention is generally to
silence expected warnings or notices. However, it currently also silences
fatal errors. As fatal errors also abort request execution, the result will
often be a hard
Hi internals,
When the silencing operator @ is used, the intention is generally to
silence expected warnings or notices. However, it currently also silences
fatal errors. As fatal errors also abort request execution, the result will
often be a hard to debug white screen of death.
The most
23 matches
Mail list logo
