# [VOTE] Allowing use of exceptions in the engine

- Thread: https://externals.io/message/70520
- Original archive: https://news-web.php.net/php.internals/70520
- Started by Nikita Popov on 2013-12-07T12:57:45+00:00
- Messages: 30
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/70520.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #70520 — Nikita Popov — 2013-12-07T12:57:45+00:00

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

Hi internals!

I opened the vote on the "Exceptions in the engine" RFC:

    https://wiki.php.net/rfc/engine_exceptions#vote

The vote has three options, "Yes", "No" and "Yes, without
 `E_RECOVERABLE_ERROR` changes". The last option is a version of the proposal
without BC issues.

Some further notes:
 * I will not be including something like BaseException. Introducing it for
this purpose seems like bad design and will be very hard to get rid of in
the future. As the proposal (without recoverable errors) does not break BC
[1] even without it, I don't see a reason to introduce it.
 * Some people suggest to use different subclasses of EngineException for
different error types. I'm not against that, but I think it's okay to do
that in a separate proposal, if someone can come up with a good selection
of exception classes. It's much easier (and does not break BC) to add
subclassing later, than to add suboptimal subclass types now and try to fix
something like the SPL exception mess later.
 * The suggested uncaught exception error message change is just a bit of
cosmetics (and not directly related to this proposal), so I'd like to do
that separately.

And regarding the vote: If you are in favor of the proposal in general, but
want to have it in PHP 6 rather than PHP 5.6, then vote "No" here. If it
fails now, someone can revive this once the time for PHP 6 has come.

Thanks,
Nikita

[1]: We don't have a formal definition for this, but it seems to be general
consensus that relaxing error conditions does not constitute a backwards
compatibility break.

---

## #70521 — Ferenc Kovacs — 2013-12-07T17:05:20+00:00

URL: https://externals.io/message/70520#70521 · In reply to: #70520

> Hi internals!
>
> I opened the vote on the "Exceptions in the engine" RFC:
>
>     https://wiki.php.net/rfc/engine_exceptions#vote
>
> The vote has three options, "Yes", "No" and "Yes, without
> `E_RECOVERABLE_ERROR` changes". The last option is a version of the proposal
> without BC issues.
>
> Some further notes:
>  * I will not be including something like BaseException. Introducing it for
> this purpose seems like bad design and will be very hard to get rid of in
> the future. As the proposal (without recoverable errors) does not break BC
> [1] even without it, I don't see a reason to introduce it.
>  * Some people suggest to use different subclasses of EngineException for
> different error types. I'm not against that, but I think it's okay to do
> that in a separate proposal, if someone can come up with a good selection
> of exception classes. It's much easier (and does not break BC) to add
> subclassing later, than to add suboptimal subclass types now and try to fix
> something like the SPL exception mess later.
>  * The suggested uncaught exception error message change is just a bit of
> cosmetics (and not directly related to this proposal), so I'd like to do
> that separately.
>
> And regarding the vote: If you are in favor of the proposal in general, but
> want to have it in PHP 6 rather than PHP 5.6, then vote "No" here. If it
> fails now, someone can revive this once the time for PHP 6 has come.
>
> Thanks,
> Nikita
>
> [1]: We don't have a formal definition for this, but it seems to be general
> consensus that relaxing error conditions does not constitute a backwards
> compatibility break.
>

personally I have seen catch-all blocks in the wild (try {//do something}
catch(Exception $e) {//do nothing}), which would behave differently (and
some of them would screw something up instead of terminating the app) if
the EngineException is a subclass of Exception.
I can see myself supporting this proposal for 5.6, if we can have it done
in a truly BC-safe manner, but I can understand, if the required
compromises for that would make the feature too "clunky", so maybe it would
be better to introduce it in a major version.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

---

## #70523 — Adam Harvey — 2013-12-07T21:47:20+00:00

URL: https://externals.io/message/70520#70523 · In reply to: #70520

> I opened the vote on the "Exceptions in the engine" RFC:
>
>     https://wiki.php.net/rfc/engine_exceptions#vote
>
> The vote has three options, "Yes", "No" and "Yes, without
> `E_RECOVERABLE_ERROR` changes". The last option is a version of the proposal
> without BC issues.
>
> And regarding the vote: If you are in favor of the proposal in general, but
> want to have it in PHP 6 rather than PHP 5.6, then vote "No" here. If it
> fails now, someone can revive this once the time for PHP 6 has come.

To be clear: I've voted -1 for exactly this reason, and this reason
alone. I don't think implementing this piecemeal (without the
 `E_RECOVERABLE_ERROR` changes) is the right way to go — I would prefer
to have the whole thing as part of a 6.0 release, rather than
potentially confusing users with a partial implementation.

Notes on the notes:

>  * I will not be including something like BaseException. Introducing it for
> this purpose seems like bad design and will be very hard to get rid of in
> the future. As the proposal (without recoverable errors) does not break BC
> [1] even without it, I don't see a reason to introduce it.

+1. I think I said last time that it felt like the
mysql_real_escape_string() of exception API design. :)

>  * Some people suggest to use different subclasses of EngineException for
> different error types. I'm not against that, but I think it's okay to do
> that in a separate proposal, if someone can come up with a good selection
> of exception classes. It's much easier (and does not break BC) to add
> subclassing later, than to add suboptimal subclass types now and try to fix
> something like the SPL exception mess later.

Also +1.

Adam

---

## #70524 — Andrea Faulds — 2013-12-07T22:09:59+00:00

URL: https://externals.io/message/70520#70524 · In reply to: #70523

>
> To be clear: I've voted -1 for exactly this reason, and this reason
> alone. I don't think implementing this piecemeal (without the
> `E_RECOVERABLE_ERROR` changes) is the right way to go — I would prefer
> to have the whole thing as part of a 6.0 release, rather than
> potentially confusing users with a partial implementation.
>

Maybe I'm misunderstanding you here, but if you don't want it piecemeal, 
surely just vote "Yes"? Or are you saying you want it in 6.0, and also 
that it shouldn't be piecemeal?

-- 
Andrea Faulds
http://ajf.me/

---

## #70525 — Adam Harvey — 2013-12-07T22:28:23+00:00

URL: https://externals.io/message/70520#70525 · In reply to: #70524

> 
> > […]
>
> Maybe I'm misunderstanding you here, but if you don't want it piecemeal,
> surely just vote "Yes"? Or are you saying you want it in 6.0, and also that
> it shouldn't be piecemeal?

I guess I explained that badly. :) The latter: I want it in 6.0, and
don't think it should be piecemeal.

Adam

---

## #70526 — Nikita Popov — 2013-12-07T23:31:41+00:00

URL: https://externals.io/message/70520#70526 · In reply to: #70523

> 
> > […]
> proposal
> > […]
> but
> > […]
>
> To be clear: I've voted -1 for exactly this reason, and this reason
> alone. I don't think implementing this piecemeal (without the
> `E_RECOVERABLE_ERROR` changes) is the right way to go — I would prefer
> to have the whole thing as part of a 6.0 release, rather than
> potentially confusing users with a partial implementation.
>

If you're concerned about `E_RECOVERABLE_ERROR` in particular I should point
out that there are very few recoverable fatals in the engine. Actually, the
only common recoverable error is the typehint violation error. The others
are along the lines of "Instantiation of 'Closure' is not allowed" or
"Closure object cannot have properties" - not something you usually
encounter. For a full list see
http://lxr.php.net/search?q=E_RECOVERABLE_ERROR&defs=&refs=&path=Zend&hist=&project=PHP_TRUNK.
So I don't think that `E_RECOVERABLE_ERROR` is a particularly large loss in
itself - but the "partial implementation" argument presumably still stands
even without it (won't be able to port all fatal errors at once, after all.)

Nikita

---

## #70528 — Nikita Popov — 2013-12-08T11:48:42+00:00

URL: https://externals.io/message/70520#70528 · In reply to: #70521

> personally I have seen catch-all blocks in the wild (try {//do something}
> catch(Exception $e) {//do nothing}), which would behave differently (and
> some of them would screw something up instead of terminating the app) if
> the EngineException is a subclass of Exception.
> I can see myself supporting this proposal for 5.6, if we can have it done
> in a truly BC-safe manner, but I can understand, if the required
> compromises for that would make the feature too "clunky", so maybe it would
> be better to introduce it in a major version.
>

I'm not sure I see how catch-all blocks relate to BC-safety as far as
 `E_ERROR` is concerned. If an engine exception is accidentally caught by a
catch-all block, it means that previously it was throwing a fatal error,
which means that your code didn't work anyway - in all likeliness you were
getting a WSOD or ISE. The catch-all block will not break the code (it is
already broken), it will only change the way in which it fails (or prevent
it from failing altogether). Of course, unintentionally missing an error
*is* an issue, but it's not an issue of BC.

Nikita

---

## #70529 — Jakub Zelenka — 2013-12-08T12:51:07+00:00

URL: https://externals.io/message/70520#70529 · In reply to: #70528

> 
>
> > […]
> would
> > […]
>
> I'm not sure I see how catch-all blocks relate to BC-safety as far as
> `E_ERROR` is concerned. If an engine exception is accidentally caught by a
> catch-all block, it means that previously it was throwing a fatal error,
> which means that your code didn't work anyway - in all likeliness you were
> getting a WSOD or ISE. The catch-all block will not break the code (it is
> already broken), it will only change the way in which it fails (or prevent
> it from failing altogether). Of course, unintentionally missing an error
> *is* an issue, but it's not an issue of BC.
>
> Nikita


I think that the problem could be code like this:

try {
// do same stuff
} catch (Exception $e) {}
delete_something_important();

I haven't tested the patch but from what I read it seems that
delete_something_important() would be now called even if there was a fatal
error in the try block?

In addition there is a small BC break that should be probably mentioned in
RFC. All apps with defined EngineException will not work. I actually found
one open source app. It's the first version of ORM Propel:

https://github.com/propelorm/Propel/blob/master/generator/lib/exception/EngineException.php

It looks that it's still used quite a few users (even there is a version 2
that resolved this using ns). I believe that there can be more closed
source apps so it should be at least mentioned in RFC...

Jakub

---

## #70531 — Jakub Zelenka — 2013-12-08T13:14:13+00:00

URL: https://externals.io/message/70520#70531

>
>
> 
>
> > […]
> Code which is that naïve probably doesn't run safely anyway, I doubt we
> should worry about it.
>
>
That's, of course, a simplified example! You can have code much more
complex with similar result. The point was that you would be able to catch
a fatal error and then do some nasty stuff after that... :)

---

## #70532 — Zeev Suraski — 2013-12-08T13:55:04+00:00

URL: https://externals.io/message/70520#70532 · In reply to: #70520

Nikita,

Apologies for not having followed the discussion a few weeks ago but I
think this proposal can't be accepted as it is even if everyone likes it.
It breaks a very basic design concept in the way both the engine code as
well as extension code is written - execution will never resume beyond an
E_ERROR.

Allowing execution to resume (through the use of exceptions) opens a huge
can of worms, and sets expectations we can't meet.  In fact, the main
difference between `E_ERROR` and `E_WARNING` is the recoverability, so this is
not some small detail we can fix - we simply can't assume execution can
continue after an `E_ERROR` is triggered, because `E_ERROR` in its very
essence implies no-resumed-execution.  That's also the reason error
handlers (that existed before exceptions did) don't handle E_ERROR.

I don't think a vote makes a lot of sense here, since it's asking people
whether they're in favor of the concept of being able to recover from any
kind of error.  That's the wrong question (to which, by the way, I'd vote
'yes').  The real question is whether people are OK that the engine will
start randomly crashing through the use of standard PHP code, which is
pretty much out of the question.

If there are E_ERROR's which you think are erroneously tagged as E_ERROR's
and should in fact be E_RECOVERABLE_ERROR, we should change them, rather
than assuming that E_ERRORs can be tagged as recoverable wholesale...

Disclaimer:  Perhaps I'm missing something.  I also asked Dmitry to take a
closer look at this...

Zeev


> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv@gmail.com]
> Sent: Saturday, December 07, 2013 2:58 PM
> To: PHP internals
> Subject: [PHP-DEV] [VOTE] Allowing use of exceptions in the engine
>
> Hi internals!
>
> I opened the vote on the "Exceptions in the engine" RFC:
>
>     https://wiki.php.net/rfc/engine_exceptions#vote
>
> The vote has three options, "Yes", "No" and "Yes, without
> `E_RECOVERABLE_ERROR` changes". The last option is a version of the
> proposal without BC issues.
>
> Some further notes:
>  * I will not be including something like BaseException. Introducing it
for this
> purpose seems like bad design and will be very hard to get rid of in the
> future. As the proposal (without recoverable errors) does not break BC
[1]
> even without it, I don't see a reason to introduce it.
>  * Some people suggest to use different subclasses of EngineException
for
> different error types. I'm not against that, but I think it's okay to do
that in a
> separate proposal, if someone can come up with a good selection of
> exception classes. It's much easier (and does not break BC) to add
> subclassing later, than to add suboptimal subclass types now and try to
fix
> something like the SPL exception mess later.
>  * The suggested uncaught exception error message change is just a bit
of
> cosmetics (and not directly related to this proposal), so I'd like to do
that
> separately.
>
> And regarding the vote: If you are in favor of the proposal in general,
but
> want to have it in PHP 6 rather than PHP 5.6, then vote "No" here. If it
fails
> now, someone can revive this once the time for PHP 6 has come.
>
> Thanks,
> Nikita
>
> [1]: We don't have a formal definition for this, but it seems to be
general
> consensus that relaxing error conditions does not constitute a backwards
> compatibility break.

---

## #70533 — Nikita Popov — 2013-12-08T14:18:20+00:00

URL: https://externals.io/message/70520#70533 · In reply to: #70532

> Nikita,
>
> Apologies for not having followed the discussion a few weeks ago but I
> think this proposal can't be accepted as it is even if everyone likes it.
> It breaks a very basic design concept in the way both the engine code as
> well as extension code is written - execution will never resume beyond an
> E_ERROR.
>
> Allowing execution to resume (through the use of exceptions) opens a huge
> can of worms, and sets expectations we can't meet.  In fact, the main
> difference between `E_ERROR` and `E_WARNING` is the recoverability, so this is
> not some small detail we can fix - we simply can't assume execution can
> continue after an `E_ERROR` is triggered, because `E_ERROR` in its very
> essence implies no-resumed-execution.  That's also the reason error
> handlers (that existed before exceptions did) don't handle E_ERROR.
>
> I don't think a vote makes a lot of sense here, since it's asking people
> whether they're in favor of the concept of being able to recover from any
> kind of error.  That's the wrong question (to which, by the way, I'd vote
> 'yes').  The real question is whether people are OK that the engine will
> start randomly crashing through the use of standard PHP code, which is
> pretty much out of the question.
>
> If there are E_ERROR's which you think are erroneously tagged as E_ERROR's
> and should in fact be E_RECOVERABLE_ERROR, we should change them, rather
> than assuming that E_ERRORs can be tagged as recoverable wholesale...
>

Hi Zeev!

I think this is a misunderstanding... I'm not suggesting to simply let the
engine continue after an `E_ERROR` - as you pointed out, that would likely
just crash it a few lines further down.

This RFC is mainly a policy RFC: The goal is to allow the use of exceptions
in the engine and to allow changing existing fatal errors to exceptions.
The change from fatal errors to exceptions needs to happen manually, by
adjusting the surrounding code to support continued execution (usually that
means freeing resources + returning). A lot of fatal errors are easy to
change, others are very hard or impossible. Changing fatal errors to
exceptions rather than recoverable errors is both more useful to the end
user and technically easier (as recoverable errors need to continue
execution in the same codepath, which is often a lot harder to implement
and find appropriate semantics for), which is why I'm suggesting this
particular course of action.

So, basically what I'm suggest is what you say in the last paragraph, just
going directly to exceptions rather than converting to `E_RECOVERABLE_ERROR` 
:)

Hope this is a bit clearer.

Nikita

---

## #70534 — Zeev Suraski — 2013-12-08T14:33:52+00:00

URL: https://externals.io/message/70520#70534 · In reply to: #70533

>
> Hi Zeev!
>
> I think this is a misunderstanding... I'm not suggesting to simply let the
> engine continue after an `E_ERROR` - as you pointed out, that would likely
> just crash it a few lines further down.
>
> This RFC is mainly a policy RFC: The goal is to allow the use of
> exceptions in the engine and to allow changing existing fatal errors to
> exceptions. The change from fatal errors to exceptions needs to happen
> manually, by adjusting the surrounding code to support continued execution
> (usually that means freeing resources + returning). A lot of fatal errors
> are easy to change, others are very hard or impossible. Changing fatal
> errors to exceptions rather than recoverable errors is both more useful to
> the end user and technically easier (as recoverable errors need to continue
> execution in the same codepath, which is often a lot harder to implement
> and find appropriate semantics for), which is why I'm suggesting this
> particular course of action.
>
> So, basically what I'm suggest is what you say in the last paragraph, just
> going directly to exceptions rather than converting to `E_RECOVERABLE_ERROR` 
> :)
>
> Hope this is a bit clearer.
>

OK, got you.   Not using exceptions in the engine was also a design
decision (so that we don't force OO concepts on non-OO people) - need to
think if it still makes sense and get back to the vote.

Thanks!

Zeev

---

## #70541 — Hannes Magnusson — 2013-12-09T05:14:10+00:00

URL: https://externals.io/message/70520#70541 · In reply to: #70520

> Hi internals!
>
> I opened the vote on the "Exceptions in the engine" RFC:
>
>     https://wiki.php.net/rfc/engine_exceptions#vote
>
> The vote has three options, "Yes", "No" and "Yes, without
> `E_RECOVERABLE_ERROR` changes". The last option is a version of the proposal
> without BC issues.
>

Wow. This is one of the bigger language changes I have seen proposed to date.

I see the framework guys jumping in on this right away wanting pretty
OO interface of course - but hold your horses a bit.
This is a very fundamental change in the language and a vote should
not be casted lightly.

The recoverable error cases is something I argued when breaking type
hinting was decided to be E_REOCVERABLE_ERROR for reasons that still
baffle me (and depending if its extension code or userland code,
effectively continues current context or not, since internals will
most likely bail out on zpp) - but now we are talking about about
changing something much bigger then that...

If this gets accepted, what is the reason we have these error levels
at all, and shouldn't E_* friends be rewritten into more convenient
logging framework and remove the association with "errors"?

-Hannes

---

## #70543 — Dmitry Stogov — 2013-12-09T07:30:41+00:00

URL: https://externals.io/message/70520#70543 · In reply to: #70520

Hi Nikita,

The idea makes sense, but it really changes the fundamental design decision.
For now the patch misses more than 300 places where you'll have to find a
way to recover from a error state.
As you said, it's hardly possible in some cases (e.g. memory_limit
overflow).

Anyway, I'm not sure if the effort and risks of bugs and breaks cost the
ability of writing "dirty" code.

Thanks. Dmitry.




> Hi internals!
>
> I opened the vote on the "Exceptions in the engine" RFC:
>
>     https://wiki.php.net/rfc/engine_exceptions#vote
>
> The vote has three options, "Yes", "No" and "Yes, without
> `E_RECOVERABLE_ERROR` changes". The last option is a version of the proposal
> without BC issues.
>
> Some further notes:
>  * I will not be including something like BaseException. Introducing it for
> this purpose seems like bad design and will be very hard to get rid of in
> the future. As the proposal (without recoverable errors) does not break BC
> [1] even without it, I don't see a reason to introduce it.
>  * Some people suggest to use different subclasses of EngineException for
> different error types. I'm not against that, but I think it's okay to do
> that in a separate proposal, if someone can come up with a good selection
> of exception classes. It's much easier (and does not break BC) to add
> subclassing later, than to add suboptimal subclass types now and try to fix
> something like the SPL exception mess later.
>  * The suggested uncaught exception error message change is just a bit of
> cosmetics (and not directly related to this proposal), so I'd like to do
> that separately.
>
> And regarding the vote: If you are in favor of the proposal in general, but
> want to have it in PHP 6 rather than PHP 5.6, then vote "No" here. If it
> fails now, someone can revive this once the time for PHP 6 has come.
>
> Thanks,
> Nikita
>
> [1]: We don't have a formal definition for this, but it seems to be general
> consensus that relaxing error conditions does not constitute a backwards
> compatibility break.

---

## #70551 — Philip Sturgeon — 2013-12-09T15:34:09+00:00

URL: https://externals.io/message/70520#70551

> 
> > […]
>
> OK, got you.   Not using exceptions in the engine was also a design
> decision (so that we don't force OO concepts on non-OO people) - need to
> think if it still makes sense and get back to the vote.
>
> Thanks!
>
> Zeev

I think it is fair to say there is a big difference between "forcing
OO concepts on non-OO people" and which is what is being proposed
here: "this is an object which you can use if you'd like to find out
what is happening with this exception."

No PHP developer is going to get away with not using any objects ever
regardless of their preferred design approach, so offering them
exception objects is not going to frighten anyone off.

Or I missed your point. :)

---

## #70552 — Pierre Joye — 2013-12-09T15:39:03+00:00

URL: https://externals.io/message/70520#70552 · In reply to: #70520

hi,


> Hi internals!
>
> I opened the vote on the "Exceptions in the engine" RFC:
>
>     https://wiki.php.net/rfc/engine_exceptions#vote
>
> The vote has three options, "Yes", "No" and "Yes, without
> `E_RECOVERABLE_ERROR` changes". The last option is a version of the proposal
> without BC issues.
>
> Some further notes:
>  * I will not be including something like BaseException. Introducing it for
> this purpose seems like bad design and will be very hard to get rid of in
> the future. As the proposal (without recoverable errors) does not break BC
> [1] even without it, I don't see a reason to introduce it.
>  * Some people suggest to use different subclasses of EngineException for
> different error types. I'm not against that, but I think it's okay to do
> that in a separate proposal, if someone can come up with a good selection
> of exception classes. It's much easier (and does not break BC) to add
> subclassing later, than to add suboptimal subclass types now and try to fix
> something like the SPL exception mess later.
>  * The suggested uncaught exception error message change is just a bit of
> cosmetics (and not directly related to this proposal), so I'd like to do
> that separately.
>
> And regarding the vote: If you are in favor of the proposal in general, but
> want to have it in PHP 6 rather than PHP 5.6, then vote "No" here. If it
> fails now, someone can revive this once the time for PHP 6 has come.

I do not mind having it in 5.x or 6. but I do mind introducing
exceptions in the core without defining what we want. Baby steps are
nice but where do we stop at this stage then? Can we use exceptions in
extensions as well? Or in other parts of the engine? This is a very
good move forward but also a very critical move. We need to clarify
how we do it, where it can be done, naming or how we want them
exactly, etc.

That's why I can't vote yes with this exact proposal (and its state).

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #70553 — Zeev Suraski — 2013-12-09T15:58:03+00:00

URL: https://externals.io/message/70520#70553 · In reply to: #70551

> > […]
>
> I think it is fair to say there is a big difference between "forcing OO
concepts
> on non-OO people" and which is what is being proposed
> here: "this is an object which you can use if you'd like to find out
what is
> happening with this exception."
>
> No PHP developer is going to get away with not using any objects ever
> regardless of their preferred design approach, so offering them
exception
> objects is not going to frighten anyone off.

While I disagree that all PHP developers would have to use objects (you
can live a full healthy procedural life in PHP) - regardless, exceptions
and their jargon is a much more advanced OO concept than just using plain
objects.  Throwing, catching, propagation rules, try/catch/finally - those
all come hand in hand with exceptions.  We've made a conscious decision
not to force this on users back when we introduced exceptions, and keep
the engine use errors only (which can be converted to exceptions easily
enough using error handlers).

Note that I think that this part is debatable - I'm a lot more worried on
the feedback Dmitry provided earlier today (although I admit I'm not crazy
of just keeping things the way they, and letting those who are interested
in exceptions convert errors to exceptions on their own).

Zeev

---

## #70554 — Philip Sturgeon — 2013-12-09T16:06:36+00:00

URL: https://externals.io/message/70520#70554 · In reply to: #70553

> > […]
> concepts
> > […]
> what is
> > […]
> exception
> > […]
>
> While I disagree that all PHP developers would have to use objects (you
> can live a full healthy procedural life in PHP) - regardless, exceptions
> and their jargon is a much more advanced OO concept than just using plain
> objects.  Throwing, catching, propagation rules, try/catch/finally - those
> all come hand in hand with exceptions.  We've made a conscious decision
> not to force this on users back when we introduced exceptions, and keep
> the engine use errors only (which can be converted to exceptions easily
> enough using error handlers).
>
> Note that I think that this part is debatable - I'm a lot more worried on
> the feedback Dmitry provided earlier today (although I admit I'm not crazy
> of just keeping things the way they, and letting those who are interested
> in exceptions convert errors to exceptions on their own).
>
> Zeev

Right, you can absolutely live a full and healthy life in PHP using
entirely procedural code (things like the dual interfaces for MySQLi
ensure that) but I really really do not see "here is an object,
try/catch/finally or EngineException" as "forcing OO concepts on
non-OO people" because it isn't. The user does not need to worry about
propogation rules unless they start writing their own exceptions and
try/catch/finally is not inherently OOP. Even if it was the average
procedural user is just going to see the difference of "Fatal Error
you code is screwed" changing to "Uncaught Engine Exception your code
is screwed" if they don't want to bother catching anything, which they
wouldn't if they didnt want to use try/catch... so the whole thing is
a bit of a non-argument.

I know it is not your main concern, but I really don't want this
argument being used as one against this RFC in general.

---

## #70555 — Zeev Suraski — 2013-12-09T16:22:37+00:00

URL: https://externals.io/message/70520#70555 · In reply to: #70554

> Right, you can absolutely live a full and healthy life in PHP using
entirely
> procedural code (things like the dual interfaces for MySQLi ensure that)
but I
> really really do not see "here is an object, try/catch/finally or
> EngineException" as "forcing OO concepts on non-OO people" because it
> isn't. The user does not need to worry about propogation rules unless
they
> start writing their own exceptions and try/catch/finally is not
inherently OOP.
> Even if it was the average procedural user is just going to see the
difference
> of "Fatal Error you code is screwed" changing to "Uncaught Engine
Exception
> your code is screwed" if they don't want to bother catching anything,
which
> they wouldn't if they didnt want to use try/catch... so the whole thing
is a bit
> of a non-argument.

Our implementation of exceptions is very much OO, borrowed from Java
(which in turn borrowed a lot from C++).  You need to understand a fair
bit and know some extra syntax to exceptions properly, even if you don't
write new exception classes.  We can agree to disagree though, I don't
think we'll change each other's mind :)

> I know it is not your main concern, but I really don't want this
argument
> being used as one against this RFC in general.

For me it is an argument.  Instead of being able to handle these errors in
the same way they handle all other errors, now they have to learn new
syntax and concepts.  I see no reason to change the status quo, which
allows those who want exceptions to easily convert errors to thrown
exceptions, into a state where those who don't want to use exceptions are
forced to use them.  Again, it's entirely fair that we disagree...

Zeev

---

## #70556 — Seva Lapsha — 2013-12-09T16:33:20+00:00

URL: https://externals.io/message/70520#70556 · In reply to: #70555

>
> For me it is an argument.  Instead of being able to handle these errors in
> the same way they handle all other errors, now they have to learn new
> syntax and concepts.  I see no reason to change the status quo, which
> allows those who want exceptions to easily convert errors to thrown
> exceptions, into a state where those who don't want to use exceptions are
> forced to use them.  Again, it's entirely fair that we disagree...


Sorry for intruding, but - I as a user (and I'm sure many would agree)
would be happy to have a configuration level choice to either get an
exception thrown or a fatal error.

Thx,
Seva

---

## #70557 — Nikita Popov — 2013-12-09T16:41:23+00:00

URL: https://externals.io/message/70520#70557 · In reply to: #70555

> For me it is an argument.  Instead of being able to handle these errors in
> the same way they handle all other errors, now they have to learn new
> syntax and concepts.  I see no reason to change the status quo, which
> allows those who want exceptions to easily convert errors to thrown
> exceptions, into a state where those who don't want to use exceptions are
> forced to use them.  Again, it's entirely fair that we disagree...
>

You can't convert fatal errors to exceptions using an error handler. That's
why I'm targeting fatal errors here and not all errors in general. While
I'm not a big fan of PHP's error system in general, it's easy enough to
turn warnings or notices into exceptions via error handlers. But for fatal
errors that's just not possible.

To achieve what I want it would be enough to turn fatal errors into
recoverable fatal errors, that would already allow the error handler
approach. But that's a lot harder to do (and imho less usable) than
directly using exceptions. Keeping the engine stable after an exceptions is
relatively simple, the same can't be said about recoverable fatals.

Regarding the "forcing OO concepts": As Philip pointed out, unless you
already make use of try/catch a fatal error and an uncaught exception are
about the same to the end user - actually, an uncaught exception is just a
special fatal error. I could totally understand your concerns - if this
discussion weren't about fatal errors. E.g. changing a warning to an
exception would cause lots of issues. The @ operator would stop working and
people would be forced to use try/catch. But for fatals @ never worked in
the first place. You can't handle them right now. Changing them to
exceptions adds the ability to handle them via try/catch, but of course you
don't need to do them. You can let them bubble (and in most cases that's
what you should do) and let them effectively act the same way as a fatal
error currently does, just with a bit of a different message ;)

Thanks,
Nikita

---

## #70562 — Nikita Popov — 2013-12-09T18:09:55+00:00

URL: https://externals.io/message/70520#70562 · In reply to: #70552

> I do not mind having it in 5.x or 6. but I do mind introducing
> exceptions in the core without defining what we want. Baby steps are
> nice but where do we stop at this stage then? Can we use exceptions in
> extensions as well? Or in other parts of the engine? This is a very
> good move forward but also a very critical move. We need to clarify
> how we do it, where it can be done, naming or how we want them
> exactly, etc.
>
> That's why I can't vote yes with this exact proposal (and its state).
>

Is there something particular that you would like to have clarified or
specified? I tried to keep the scope narrow - only engine and only fatal
errors, but if you wish to have stricter specification on some parts,
please say so.

About your particular questions:

> Can we use exceptions in extensions as well?
This RFC is only about the engine - it does not affect our standard library
exts. The rules there stay the same: Functions throw warnings/notices,
methods may throw exceptions.

> Or in other parts of the engine?
What do you mean by "other parts"? I'm referring to the Zend engine as a
whole, though primarily the executor, because converting compile-time
errors will require more careful planning.

Thanks,
Nikita

---

## #70563 — Philip Sturgeon — 2013-12-09T18:10:17+00:00

URL: https://externals.io/message/70520#70563 · In reply to: #70557

> 
> > […]
>
>
> You can't convert fatal errors to exceptions using an error handler. That's
> why I'm targeting fatal errors here and not all errors in general. While I'm
> not a big fan of PHP's error system in general, it's easy enough to turn
> warnings or notices into exceptions via error handlers. But for fatal errors
> that's just not possible.
>
> To achieve what I want it would be enough to turn fatal errors into
> recoverable fatal errors, that would already allow the error handler
> approach. But that's a lot harder to do (and imho less usable) than directly
> using exceptions. Keeping the engine stable after an exceptions is
> relatively simple, the same can't be said about recoverable fatals.
>
> Regarding the "forcing OO concepts": As Philip pointed out, unless you
> already make use of try/catch a fatal error and an uncaught exception are
> about the same to the end user - actually, an uncaught exception is just a
> special fatal error. I could totally understand your concerns - if this
> discussion weren't about fatal errors. E.g. changing a warning to an
> exception would cause lots of issues. The @ operator would stop working and
> people would be forced to use try/catch. But for fatals @ never worked in
> the first place. You can't handle them right now. Changing them to
> exceptions adds the ability to handle them via try/catch, but of course you
> don't need to do them. You can let them bubble (and in most cases that's
> what you should do) and let them effectively act the same way as a fatal
> error currently does, just with a bit of a different message ;)
>
> Thanks,
> Nikita

Right. Put simply:

1. Users who previously did not care about exceptions will continue to
not care about exceptions, and do not have to do anything any
differently.
2. Users who want to handle fatal errors somehow (because you
currently cannot) can use this to catch them.

Nobody needs to work with exceptions if they dont want to, that fatal
error just shows up as a uncaught backtrace and fatals errors just
like it used to.

Seems like a win win.

---

## #70565 — Pierre Joye — 2013-12-09T18:25:39+00:00

URL: https://externals.io/message/70520#70565 · In reply to: #70562

>
> 
> > […]
>
>
> Is there something particular that you would like to have clarified or
specified? I tried to keep the scope narrow - only engine and only fatal
errors, but if you wish to have stricter specification on some parts,
please say so.

I would prefer to see introduce exceptions in the whole core and clearly
define how we want them or where. Adding very good documentation is also a
requirement (see Zeev's reply).

Not doing may lead to half backed support with everyone doing its little
sauce and will end as a big mess. We should avoid that.

> About your particular questions:
>
>
> > […]
> This RFC is only about the engine - it does not affect our standard
library exts. The rules there stay the same: Functions throw
warnings/notices, methods may throw exceptions.

Right, everyone does his thing and it is not confusing and inconsistent.
Let solve the whole thing instead of a rather limited and not so useful.

>
> > […]
> What do you mean by "other parts"? I'm referring to the Zend engine as a
whole, though primarily the executor, because converting compile-time
errors will require more careful planning.

As of other errors, functions, operators, etc.

Cheers,
Pierre

---

## #70568 — Zeev Suraski — 2013-12-10T12:55:07+00:00

URL: https://externals.io/message/70520#70568 · In reply to: #70563

Nikita, Philip, see below:

> -----Original Message-----
> From: Philip Sturgeon [mailto:pjsturgeon@gmail.com]
> Sent: Monday, December 09, 2013 8:10 PM
> To: Nikita Popov
> Cc: Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] [VOTE] Allowing use of exceptions in the engine
>
> On Mon, Dec 9, 2013 at 11:41 AM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> > […]

That's correct, but you seem to be ignoring the reason for that.  It's not
an arbitrary decision, but rather, the semantics of what fatal errors are.
They're fatal, not recoverable (with the reason being that the
engine/extension/whatever may be in an unstable state), and therefore it
should not be possible to use *any* mechanism to recover from them, be
them error handlers or exceptions.

> > […]
recoverable
> fatals.

In both cases, the complexity isn't in the code that would trigger the
error/exception.  The complexity is that you now put the burden of keeping
all the data structures of the engine/extension in a 100% working state,
while the current semantics is that code execution will never resume.
While you pointed out in the RFC a specific example of a place where an
exception would be a bit easier to implement than an error, it's a very
specialized example - errors that happen on the void between two function
scopes - and doesn't hold true for most errors.  I don't think it makes
sense to say it's significantly easier to turn fatal errors into
exceptions than turning fatal errors into recoverable errors.

> > […]

First off, there should be no concept of 'recoverable fatal error'.  If
it's fatal, it cannot be recoverable and vice versa.  The real term should
just be 'recoverable error'.  That small detail may be in the root of our
misunderstanding.  All the negative side effects listed in the RFC for
fatal errors are in there *by design*, since we cannot guarantee that if
we run the destructors/finally blocks or otherwise allow graceful
handling, this will not result in a segfault.  That's exactly the whole
idea beyond a fatal (by definition non-recoverable) error.

Secondly, the patch radically changes execution behavior in case of
recoverable errors for people using error handlers and arguably in a very
bad way, effectively forcing them to start using exceptions if they want
to truly recover from the error.  Otherwise, by the time the exception
turns into an error, there's nothing you can recover (you've already
bubbled up all the way to the global scope).  That will break apps relying
on the current behavior.

Last, in the RFC it mentions that 'recoverable errors are hard to catch'.
That you're forced to use an error_handler.  How are they any different
from any other error/warning type?  While you (and many others) have bias
for using exception handling, others prefer using error_handlers
especially when writing procedural code.  Changing errors to exceptions
using an error handler is trivial (and we can also implement Seva's
suggestion of having an INI directive for that, although I think using a
serializable error handler makes more sense).  The reverse, however, is
not even possible.  So I very much stand by what I said, that if we accept
this RFC, we're forcing OO concepts (or the try/catch concept) on all
users which is something that we intentionally wanted to avoid.  Users who
could use centralized error handlers will no longer be able to do so and
handle recoverable errors.

> > […]


Again, I think that in the majority of the cases, if you can safely turn
an `E_ERROR` onto an exception, you can just as easily turn it into an
E_RECOVERABLE_ERROR.  It makes no sense, IMHO, to tie this effort together
with changing the semantics of how the engine reports problems, and more
so - change it in a way that inconsistent across different error types AND
breaks backwards compatibility in a pretty big way (for recoverable
errors).

> 1. Users who previously did not care about exceptions will continue to
not
> care about exceptions, and do not have to do anything any differently.

Given that most (all minus one) of the people in favor of this idea voted
'yes' and not for the second 'yes w/o E_RECOVERABLE_ERROR', that's not
exactly accurate.  That means that recovery code that worked fine with
 `E_RECOVERABLE_ERROR` will now break, and it won't be possible to fix it w/o
learning exceptions and adding try/catch blocks all over the application.

> 2. Users who want to handle fatal errors somehow (because you currently
> cannot) can use this to catch them.

I think we're way too optimistic about the ability to recover from places
which are marked by `E_ERROR` today, and that turning them to exceptions is
hardly the magical solution that just makes all the
inconsistency/stability issues go poof.

> Nobody needs to work with exceptions if they dont want to, that fatal
error
> just shows up as a uncaught backtrace and fatals errors just like it
used to.
>
> Seems like a win win.

Seems more like a lose/risk situation to me (lose BC for recoverable
errors, take risk with inconsistent data structures for fatal errors).

Zeev

---

Next page: https://externals.io/message/70520.md?page=2