Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85766
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLuZqc6czDWB9B-4UKuji9L3LOf+LfY8cnujmT6M0=TBHw@mail.gmail.com>
References: <CAF+90c89oL54vo556WMtuZKPZu_5WkL1AHt=RFS__Kdwt1X4Rg@mail.gmail.com>
	<CA+9eiLuZqc6czDWB9B-4UKuji9L3LOf+LfY8cnujmT6M0=TBHw@mail.gmail.com>
Date: Fri, 10 Apr 2015 12:11:40 +0200
Message-ID: <CAF+90c9WH0V1fVux0guBVTj5EtK--5M1zuaJF58Ltrwx=vCh6w@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bb042be8dae2d05135bfd51
Subject: Re: [PHP-DEV] Exception message cleanup
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7bb042be8dae2d05135bfd51
Content-Type: text/plain; charset=UTF-8

On Fri, Apr 10, 2015 at 1:32 AM, Dmitry Stogov <dmitry@zend.com> wrote:

>
>
> On Thu, Apr 9, 2015 at 11:04 AM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
>> Hi internals!
>>
>> A lot of people have been confused about engine exceptions currently
>> displaying as normal fatal errors (if they aren't caught). We'll have to
>> change this to use exception messages.
>>
>> Before doing this I'd like to clean up the messages a bit to make them
>> more
>> friendly for CLI usage. Currently the messages are so cluttered that it's
>> hard to find the actual error message if you're in an 80 char window.
>>
>> Patch is here: https://github.com/php/php-src/pull/1226
>>
>> Previous message:
>>
>> Fatal error: Uncaught exception 'UnexpectedValueException' with message
>> 'Failed to open directory ""' in %s:%d
>> Stack trace:
>> #0 %s(%d): DirectoryIterator->__construct('\x00/abc')
>> #1 {main}
>>   thrown in %s on line %d
>>
>> New message:
>>
>> UnexpectedValueException: Failed to open directory "" in %s on line %d
>> Stack trace:
>> #0 %s(%d): DirectoryIterator->__construct('\x00/abc')
>> #1 {main}
>>
>> Essentially exceptions would display like ordinary error, but with "Fatal
>> error" / "Warning" / ... replaced by the exception name, and showing a
>> stack trace after the error.
>>
>> A side-effect of the change is that uncaught exceptions will always be
>> displayed canonically and not based on __toString output. To modify
>> display
>> of exception output, people should modify the respective properties of the
>> exception.
>>
>> Any objections to this?
>>
>
> We will have to change half of PHPT tests.
> New tests with fatal errors are going to be incompatible between PHP-5 and
> PHP-7.
> Log analysers written for PHP-5  won't work with PHP-7.
>

I've been getting a lot of "bug reports" about how this behavior and that
behavior is giving them a "Fatal error" in PHP 7, even though it's supposed
to be an exception. I don't think it's viable to leave the engine exception
messages as they are now. Especially as some fatals really are fatals and
not exceptions and it's currently impossible to distinguish which are which
based on the message (and it's also not visible what kind of exception was
thrown, e.g. whether it was a TypeException).

Nikita

--047d7bb042be8dae2d05135bfd51--