On 06/23/2012 04:06 PM, Stas Malyshev wrote:
> Hi!
>
>> Maybe it is simply time to rethink the error handling.
>
> This is true, current error handling has many deficiencies and is also
> very expensive even when the errors are muted (we still produce the
> whole error string, etc. even if we nev
Hi!
> Maybe it is simply time to rethink the error handling.
This is true, current error handling has many deficiencies and is also
very expensive even when the errors are muted (we still produce the
whole error string, etc. even if we never display it). Unfortunately, BC
concerns prevailed last
On Sun, 2012-06-24 at 00:24 +0200, Nikita Popov wrote:
> Yes, I feel like we must discuss this a thousand times anew. There
> clearly is no consensus about it. Just look at the responses in this
> thread and in other discussions relating this issue. When people read
> "throws a warning, but only if
On Sat, 23 Jun 2012 21:53:01 +0200, Stas Malyshev
wrote:
Hi!
The warning for invalid UTF-8 stays intact and is thrown also with
display_errors = On. If this behavior is undesired this can be remedied
later.
Must we discuss it 1000 times anew? There was a reason why it didn't
throw warning
On Sat, Jun 23, 2012 at 9:53 PM, Stas Malyshev wrote:
> Hi!
>
>> The warning for invalid UTF-8 stays intact and is thrown also with
>> display_errors = On. If this behavior is undesired this can be remedied
>> later.
>
> Must we discuss it 1000 times anew? There was a reason why it didn't
> throw
Hi!
> I'm open to changing or aliasing the name to array_pluck(), if others
> are in agreement.
I wouldn't know what "pluck" means here. "Column" is a clear word with
established meaning. Let's not get too whimsical here.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.c
On Sat, Jun 23, 2012 at 9:53 PM, Stas Malyshev wrote:
> Hi!
>
> > The warning for invalid UTF-8 stays intact and is thrown also with
> > display_errors = On. If this behavior is undesired this can be remedied
> > later.
>
> Must we discuss it 1000 times anew? There was a reason why it didn't
> thr
Hi!
> The warning for invalid UTF-8 stays intact and is thrown also with
> display_errors = On. If this behavior is undesired this can be remedied
> later.
Must we discuss it 1000 times anew? There was a reason why it didn't
throw warning when display_errors is on. The reason is that it is very
e
I applied a few changes in
https://github.com/php/php-src/commit/84fe2cc890e49f40bac7c3ba74b3cfc6dc4cef2f
and
https://github.com/php/php-src/commit/36fa17a5fae84ab332366a202f0a709279a2466a.
>From the commit message:
<
json_encode() now returns bool(false) for all possible errors, throws the
r
>
> The problem with a warning here is that there is usually no way to
> prevent it short of using @ or preceding all calls to htmlspecialchars()
> with an iconv() call. A bad guy can simply send invalid UTF-8 bytes to a
> web app and look for that warning to get a really good idea about the
> serv
10 matches
Mail list logo