On Wed, 26 Aug 2009, Greg Beaver wrote:
> Derick Rethans wrote:
> > And the suggestion? Yet another ini setting (some even advocate making
> > it INI_SYSTEM, which is obviously totally wacko)... This idea is an
> > ostrich method.
>
> I'm only trying to suggest ways of fixing problems, calling
Hi!
I don't find it useful, and obviously not everybody agreed with all the
things in Chicago either. I didn't find this back in the notes either
(http://wiki.php.net/summits/pdmnotesmay09).
I got that _you_ don't find it useful. I wish people could get outside
of the box and consider what o
On Wed, Aug 26, 2009 at 16:52, Greg Beaver wrote:
> performance hit when an error is completely hidden either by
> error_reporting or by @ (i.e. no track_errors, no user error handler, no
> other things that would expect to see the errors). That's all that
error_get_last()...
You can't know, at
Derick Rethans wrote:
> And the suggestion? Yet another ini setting (some even advocate making
> it INI_SYSTEM, which is obviously totally wacko)... This idea is an
> ostrich method.
Derick,
I'm only trying to suggest ways of fixing problems, calling them
"obviously wacko" is useless. I don't g
Derick Rethans wrote:
> On Tue, 25 Aug 2009, Stanislav Malyshev wrote:
>
>>> Considering that there shouldn't be any errors in the first place, this
>> You must be kidding me. Any fopen of non-existing file, and loading of
>> non-perfect XML from third party produces errors.
>
> You can test for
On Tue, 25 Aug 2009, Stanislav Malyshev wrote:
> > Considering that there shouldn't be any errors in the first place, this
>
> You must be kidding me. Any fopen of non-existing file, and loading of
> non-perfect XML from third party produces errors.
You can test for the first case, and the seco
Hi!
You're the one asking "What do you think?" :) People seem to think
that this feature is another invitation to bad practice in 95% of the
cases, and only useful to the last 5% of the people who know what
they're doing... (like goto?)
It's useful to 100% people since these practices are bein
Hello,
On Tue, Aug 25, 2009 at 6:36 PM, Stanislav Malyshev wrote:
> Hi!
>
>> Considering that there shouldn't be any errors in the first place, this
>
> You must be kidding me. Any fopen of non-existing file, and loading of
> non-perfect XML from third party produces errors. There is absolutely no
Hi!
Considering that there shouldn't be any errors in the first place, this
You must be kidding me. Any fopen of non-existing file, and loading of
non-perfect XML from third party produces errors. There is absolutely no
way you can write code that does anything useful that would guaranteedly
On Mon, 24 Aug 2009, Stanislav Malyshev wrote:
> > If you enable error log you would be able to identify errors, even
> > in legacy code fairly quickly and address them as needed. The speed
> > increase, by Stas' own admission is very minimal here, I would wager
>
> It's not "very minimal". It'
On 25-Aug-09, at 2:39 AM, Stanislav Malyshev wrote:
Hi!
If you enable error log you would be able to identify errors, even
in legacy code fairly quickly and address them as needed. The speed
increase, by Stas' own admission is very minimal here, I would wager
It's not "very minimal". It'
Hi!
If you enable error log you would be able to identify errors, even in
legacy code fairly quickly and address them as needed. The speed
increase, by Stas' own admission is very minimal here, I would wager
It's not "very minimal". It's not big overall, but it speeds up
operations affected
Hi!
That's also easily solved by making it INI_SYSTEM.
Note here that fatal errors can not be masked, for obvious reasons.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailin
Greg,
If you enable error log you would be able to identify errors, even in
legacy code fairly quickly and address them as needed. The speed
increase, by Stas' own admission is very minimal here, I would wager
that it would be small enough that on a application generating 2-3
E_STRICTs pe
Ilia Alshanetsky wrote:
>
> On 24-Aug-09, at 6:54 PM, Greg Beaver wrote:
>>
>> 2) as long as the patch does not break any backwards compatibility
>> (error logging still works as it always did independent of error_mask,
>> user error handlers still get the same stuff), why would we care? There
>>
Hi!
Stats "@fopen()" example is perfect here, so lets say we do add this
feature and people simply turn of error's entirely so that they can
instead write "fopen()", they feel all good about themselves, since they
handle the error locally and get a magical speed boost (noticeable or
not) .. a
On 24-Aug-09, at 6:54 PM, Greg Beaver wrote:
2) as long as the patch does not break any backwards compatibility
(error logging still works as it always did independent of error_mask,
user error handlers still get the same stuff), why would we care?
There
is a time and place for being academ
Lukas Kahwe Smith wrote:
>
> On 25.08.2009, at 00:54, Greg Beaver wrote:
>
>> 1) if a tree falls in the forest and there is no one there to hear it,
>> do we still have to put up with the performance loss?
>> 2) as long as the patch does not break any backwards compatibility
>> (error logging sti
On 25.08.2009, at 00:54, Greg Beaver wrote:
1) if a tree falls in the forest and there is no one there to hear it,
do we still have to put up with the performance loss?
2) as long as the patch does not break any backwards compatibility
(error logging still works as it always did independent of
19 matches
Mail list logo
