Rasmus Lerdorf wrote:
There will always be a reason to not report certain types of errors.
E_STRICT and E_DEPRECATED are informative development-level messages
that have no place on a production system. They should be turned off.
The actual real problem is that our error mechanism only allows us
Hi!
Of course we are well aware that you can choose to ignore errors even
today. However instead of adding yet another ini setting, some of us
feel we should rather focus on solving the real issues. That certain
This is a real issue. You have better solution for it? Go ahead, propose
it. So
On Fri, August 28, 2009 4:09 pm, Stanislav Malyshev wrote:
> Hi!
>
>> I foresee a fair number of people who turn on error_mask, and then
>> are
>> defuddled by the 3rd party apps they never reviewed in the first
>> place
>> not behaving.
> /.../
> > All that said:
> > I am in favor of this patch,
Lukas Kahwe Smith wrote:
>
> On 28.08.2009, at 23:09, Stanislav Malyshev wrote:
>
>> As I already noted, the masking - in most cases and definitely in
>> recommended cases - would happen for errors that are NOT SEEN. Not
>> reported. Not logged. Before the patch. Which means, whatever
>> advantag
On 28.08.2009, at 23:09, Stanislav Malyshev wrote:
As I already noted, the masking - in most cases and definitely in
recommended cases - would happen for errors that are NOT SEEN. Not
reported. Not logged. Before the patch. Which means, whatever
advantage you seek from looking at these err
Hi!
I foresee a fair number of people who turn on error_mask, and then are
defuddled by the 3rd party apps they never reviewed in the first place
not behaving.
/.../
> All that said:
> I am in favor of this patch, provided sufficient effort to be sure the
> community knows, in advance, loud and
On 28.08.2009, at 22:47, Richard Lynch wrote:
I must say, however, that buried in Stas' use case, 3rd party,
not-so-clean code, and realistic pragmatic installs thereof, is buried
the rather large problem:
Many people who do such a thing, do not really do a serious
code-review of the 3rd party
Personally, I generally prefer log_errors and E_ALL in production.
That said, there have been cases where it really wouldn't make much
sense to log the errors on a web tier with many nodes.
Or, at least, it didn't make sense to *just* log the errors.
But I digress.
I believe Stas has made a goo
Hi!
Sorry, I just don't get it. If the mask thing kills some level..what's
the point in enabling it in the first place? And IIRC, E_STRICT is not
part of E_ALL..
There's no point in enabling it. The point is that now PHP generates
full set of data even for DISABLED errors. And spends time/me
Daniel Convissor wrote:
Hello Jani:
On Tue, Aug 25, 2009 at 11:11:19AM +0300, Jani Taskinen wrote:
On 08/25/2009 10:35 AM, Stanislav Malyshev wrote:
Because it would break other funcions (namely, $php_errormsg, error
handlers, etc.) which may be used by some.
Well, not necessarily. How doesn't
Hello Jani:
On Tue, Aug 25, 2009 at 11:11:19AM +0300, Jani Taskinen wrote:
> On 08/25/2009 10:35 AM, Stanislav Malyshev wrote:
>>
>> Because it would break other funcions (namely, $php_errormsg, error
>> handlers, etc.) which may be used by some.
>
> Well, not necessarily. How doesn't your patch b
Hey Stas:
On Mon, Aug 24, 2009 at 11:43:22PM -0700, Stanislav Malyshev wrote:
>
> That's true. So, if you use code that uses $php_errormsg, of course you
> can not use this optimization and should not enable it (at least for
> error types and code parts that you use $php_errormsg with).
Exact
Derick Rethans wrote:
> On Mon, 24 Aug 2009, Rasmus Lerdorf wrote:
>> Lukas, the problem is that all messages, E_STRICT, E_DEPRECATED,
>> E_NOTICE, whatever, all cause a performance hit even if the
>> error_reporting level is such that they will never show up anywhere.
>> That's what this patch is
On Mon, 24 Aug 2009, Rasmus Lerdorf wrote:
> Lukas Kahwe Smith wrote:
> >
> > anyways to me both E_STRICT and E_DEPRECATED are development tools that
> > can be totally ignored in production. however E_NOTICE should not occur
> > in production and we shouldnt encourage people to make them disappe
Hi,
I think the idea is good intended but will cause troubles of introduced in
5.3. I alone have a bunch of code with custom error handlers that expect to
receive all errors at all times. If the feature allows runtime tweaking via
ini_set/get, then one could add more plumbing code and workaro
2009/8/24 Rasmus Lerdorf :
> I think we should do something along the lines of what Stas is
> suggesting. The current approach of allocating and sprintf'ing all
> messages regardless of whether they will ever be used for anything is
> painful and a huge impediment to adding informative E_NOTICE an
On 08/25/2009 10:35 AM, Stanislav Malyshev wrote:
Hi!
Just wondering why nobody hasn't suggested the obvious (?) alternative
yet: Why not fix error_reporting to work like one expects. As in: If
an error level isn't in it, then nothing happens. Adding an extra
option to do that seems a bit overk
Hi!
Just wondering why nobody hasn't suggested the obvious (?) alternative
yet: Why not fix error_reporting to work like one expects. As in: If an
error level isn't in it, then nothing happens. Adding an extra option to
do that seems a bit overkill..
Because it would break other funcions (na
On 08/25/2009 12:42 AM, Stanislav Malyshev wrote:
Hi!
Quite boring to read this thread where two persons argue about
something abstract. Stas, can you give a real life example where your
patch is necessary..?
Any code where you either use @ or error_reporting which is not -1 would
benefit fro
Hi!
@ is often used to stop error/warning output to the browser on that line,
but the next couple lines of code are used to handle that error. For
example:
if (!($dom = @DOMDocument::load($file_name))) {
log_it('invalid XML: ' . $php_errormsg);
die('invalid XML');
}
So if error proc
Hi Stas:
On Mon, Aug 24, 2009 at 12:59:55PM -0700, Stanislav Malyshev wrote:
>
> Just search for @fopen or @include or
> @xml or @eval - tons of examples.
True. But this patch could cause problems.
@ is often used to stop error/warning output to the browser on that line,
but the next couple
Hi,
Expanding on this.
In a typical project I always try to make my own code very clean by
letting it run on a staging environment with all error reporting
enabled for a while before living it; so keeping the error_reporting
enabled on the live server (and sending a daily log of caught errors)
wo
On 25.08.2009, at 00:12, Stanislav Malyshev wrote:
Hi!
Lukas, the problem is that all messages, E_STRICT, E_DEPRECATED,
E_NOTICE, whatever, all cause a performance hit even if the
error_reporting level is such that they will never show up anywhere.
That's what this patch is trying to address.
Hi!
Lukas, the problem is that all messages, E_STRICT, E_DEPRECATED,
E_NOTICE, whatever, all cause a performance hit even if the
error_reporting level is such that they will never show up anywhere.
That's what this patch is trying to address. To write optimal code,
they have to be entirely clea
On 24.08.2009, at 23:59, Rasmus Lerdorf wrote:
Lukas Kahwe Smith wrote:
On 24.08.2009, at 23:42, Stanislav Malyshev wrote:
Hi!
Quite boring to read this thread where two persons argue about
something abstract. Stas, can you give a real life example where
your
patch is necessary..?
An
hi Lukas,
On Mon, Aug 24, 2009 at 11:51 PM, Lukas Kahwe Smith wrote:
>
> On 24.08.2009, at 23:42, Stanislav Malyshev wrote:
>
>> Hi!
>>
>>> Quite boring to read this thread where two persons argue about something
>>> abstract. Stas, can you give a real life example where your patch is
>>> necessar
Lukas Kahwe Smith wrote:
>
> On 24.08.2009, at 23:42, Stanislav Malyshev wrote:
>
>> Hi!
>>
>>> Quite boring to read this thread where two persons argue about
>>> something abstract. Stas, can you give a real life example where your
>>> patch is necessary..?
>>
>> Any code where you either use @
On 24.08.2009, at 23:42, Stanislav Malyshev wrote:
Hi!
Quite boring to read this thread where two persons argue about
something abstract. Stas, can you give a real life example where
your patch is necessary..?
Any code where you either use @ or error_reporting which is not -1
would ben
Hi!
Quite boring to read this thread where two persons argue about something
abstract. Stas, can you give a real life example where your patch is
necessary..?
Any code where you either use @ or error_reporting which is not -1 would
benefit from it by not processing errors that go nowhere. I
I think we should do something along the lines of what Stas is
suggesting. The current approach of allocating and sprintf'ing all
messages regardless of whether they will ever be used for anything is
painful and a huge impediment to adding informative E_NOTICE and
E_STRICT messages in the future.
Quite boring to read this thread where two persons argue about something
abstract. Stas, can you give a real life example where your patch is necessary..?
--Jani
Stanislav Malyshev wrote:
Hi!
Unless your code is "ridden" or if you prefer "filled" with @ and/or
errors the speed improvement wo
Hi!
Unless your code is "ridden" or if you prefer "filled" with @ and/or
errors the speed improvement would be next to impossible to measure
since you'd be literally saving microseconds. You'd need to have a
Microsecond here, microsecond there - this stuff adds up. And 2-3
mallocs of substa
Stanislav Malyshev wrote:
Hi!
I've implemented a patch that allows to "mask" certain types of errors -
i.e. make PHP engine completely ignore them. Now even if the error is
not reported, it passes full cycle through message string creation, all
allocations on the way, etc. even though ultimat
On 24-Aug-09, at 3:59 PM, Stanislav Malyshev wrote:
There is very little modern code that is @ ridden like the stuff
written
If we discard emotional terms like "ridden" - there is such code in
almost every major app out there. Just search for @fopen or @include
or @xml or @eval - tons
Hi!
Because it may force to fix the errors, rather then ignore them?
Come on. That doesn't make any sense. If people deliberately disabled
the error, they don't want to see it, and they will not see it. Making
it slow doesn't do anything useful. Let's insert some sleep()'s into
zend_error()
On 24-Aug-09, at 3:30 PM, Stanislav Malyshev wrote:
Hi!
1) Once you completely hide an error there is absolutely no trace
what so ever that it has even occurred, even if its the slowdown of
the native error handler being.
That's the point. And how the slowdown would be useful?
Because
Hi!
1) Once you completely hide an error there is absolutely no trace what
so ever that it has even occurred, even if its the slowdown of the
native error handler being.
That's the point. And how the slowdown would be useful?
2) Debugging code becomes that much more trickier, since a single
Well, couple of reasons:
1) Once you completely hide an error there is absolutely no trace what
so ever that it has even occurred, even if its the slowdown of the
native error handler being.
2) Debugging code becomes that much more trickier, since a single
option effectively turns off PHP
Hi!
While the patch is certainly interesting, I think masking errors is a
really really bad idea.
Any argument as to why?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing L
Stas,
While the patch is certainly interesting, I think masking errors is a
really really bad idea.
On 24-Aug-09, at 2:17 PM, Stanislav Malyshev wrote:
Hi!
I've implemented a patch that allows to "mask" certain types of
errors - i.e. make PHP engine completely ignore them. Now even if
40 matches
Mail list logo
