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?
Thanks,
Nikita
Hi Nikita,
I like the new display format, but there's one thing I miss. If you replace
the exception name for warnings and fatals, how does a user know which
exception he has to catch?
Regards, Niklas
Nikita Popov nikita.ppv@gmail.com schrieb am Do., 09.04.2015, 10:04:
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 %dNew 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?
Thanks,
Nikita
Hi Nikita,
I like the new display format, but there's one thing I miss. If you
replace the exception name for warnings and fatals, how does a user know
which exception he has to catch?Regards, Niklas
Sorry, I don't understand what you mean here. The first part of the message
says which exception you need to catch, right?
Nikita
I like the new display format, but there's one thing I miss. If you
replace the exception name for warnings and fatals, how does a user know
which exception he has to catch?
Sorry, I don't understand what you mean here. The first part of the message
says which exception you need to catch, right?
Nikita is just voicing the same question as Patrick ...
While you are quite correct that the new exception is listed, it now
requires that all of the automatic processing knows about every new
exception in order to pick them up. What I think both are saying is it
needs some of the old wrapper ... especially when the new exception may
not even be a public one?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Nikita,
Hi Nikita,
I like the new display format, but there's one thing I miss. If you
replace the exception name for warnings and fatals, how does a user know
which exception he has to catch?Regards, Niklas
Sorry, I don't understand what you mean here. The first part of the
message
says which exception you need to catch, right?Nikita
I think he means something greppable in the output. So prefix the exception
name in your custom message with "Uncaught " so people can search the
output for "Uncaught \w+"
+1 on the change overall (with a "Uncaught" prefix before the exception
classname).
Anthony
Am 09.04.2015 10:04 schrieb "Nikita Popov" nikita.ppv@gmail.com:
New message:
UnexpectedValueException: Failed to open directory "" in %s on line %d
...
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.
Can you please keep some kind of keyword in front? I'd be most happy with
"Fatal error " followed by the exception name.... but a single "Fatal ",
"Error ", or "Uncaught " would be okay.
Otherwise, now positive grepping alerters (ours looks for "error" in the
first or second ws-separated column), would need to be changed to negative
ones (alert me immediately except for Notice, Warning, whatever comes up
later...)
We also do a daily aggregation on the first non-ws non-PHP item in the
line, which would probably need some love with that new format.
Nothing big that we couldn't work around, but IMO it always makes sense to
have clear "severity" indicators at the front of log lines.
best regards
Patrick
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 %dNew 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.
Thanks. Dmitry.
Thanks,
Nikita
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 %dNew 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
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 %dNew 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.
An update on this:
EngineException and TypeException now display as normal exceptions
(including stack trace). ParseException still show as a "Parse error". I
don't plan to change that one.
Instead of the relatively aggressive message changes described above I've
only landed a small tweak (see
https://github.com/php/php-src/commit/3ae995f03c8f60c4a4c9718262545cf5a6a08da3),
which fixes the problem with nested quotes but keeps current structure.
Nikita