# Exception message cleanup

- Thread: https://externals.io/message/85748
- Original archive: https://news-web.php.net/php.internals/85748
- Started by Nikita Popov on 2015-04-09T08:04:42+00:00
- Messages: 9
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #85748 — Nikita Popov — 2015-04-09T08:04:42+00:00

URL: https://externals.io/message/85748#85748

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

---

## #85749 — Niklas Keller — 2015-04-09T10:33:58+00:00

URL: https://externals.io/message/85748#85749 · In reply to: #85748

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 %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

---

## #85752 — Patrick Schaaf — 2015-04-09T11:21:25+00:00

URL: https://externals.io/message/85748#85752 · In reply to: #85748

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

---

## #85754 — Nikita Popov — 2015-04-09T12:55:48+00:00

URL: https://externals.io/message/85748#85754 · In reply to: #85749

> 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

---

## #85755 — Lester Caine — 2015-04-09T13:12:21+00:00

URL: https://externals.io/message/85748#85755 · In reply to: #85754

> > […]

> 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

---

## #85757 — Anthony Ferrara — 2015-04-09T15:12:52+00:00

URL: https://externals.io/message/85748#85757 · In reply to: #85754

Nikita,


>
> 
>
> > […]
> 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

---

## #85762 — Dmitry Stogov — 2015-04-09T23:32:24+00:00

URL: https://externals.io/message/85748#85762 · In reply to: #85748

> 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.

Thanks. Dmitry.


>
> Thanks,
> Nikita

---

## #85766 — Nikita Popov — 2015-04-10T10:11:40+00:00

URL: https://externals.io/message/85748#85766 · In reply to: #85762

>
>
> On Thu, Apr 9, 2015 at 11:04 AM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
> > […]
>
> 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

---

## #86387 — Nikita Popov — 2015-05-25T18:53:49+00:00

URL: https://externals.io/message/85748#86387 · In reply to: #85748

> 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.
>

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