[RFC] Exceptions in the engine

10 years ago by Lars Strojny — view source

unread

Hi Nikita,

[...]

As such I'm re-proposing this RFC for inclusion in PHP 7:

https://wiki.php.net/rfc/engine_exceptions_for_php7

The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.

I very much like the idea of making fatal errors exceptions, so: thumbs up! Is there a way to introduce different exception classes for different errors. E.g.

UndefinedMethodException for stdClass::method()
NullPointerException for null::method()
UndefinedFunctionException for invalid_function()
etc.

They could all extend EngineException to have a common base class but I am sure we could find good abstractions for an exception inheritance tree.

What do you think?

cu,
Lars

10 years ago by Rowan Collins — view source

unread

Lars Strojny wrote (on 06/10/2014):

Hi Nikita,

[...]
As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.
I very much like the idea of making fatal errors exceptions, so: thumbs up! Is there a way to introduce different exception classes for different errors. E.g.
UndefinedMethodException for stdClass::method()

NullPointerException for null::method()

UndefinedFunctionException for invalid_function()

etc.

They could all extend EngineException to have a common base class but I am sure we could find good abstractions for an exception inheritance tree.

What do you think?

It was suggested in the previous discussion that this could be added
later, but IMHO, it's a must. Part of the power of exceptions is that
you can selectively catch them when you know you can deal with the
result.

Emitting a single EngineException will just encourage a kind of "pokemon
exception handling", because the only way to use it is in a generic
"something went wrong" handler. The semantics of that handler might be a
bit tidier than one for E_RECOVERABLE_ERROR, but there's not a lot of
extra power available.

As an example where a specific exception would be useful, but a generic
one would not, consider a fluent interface which sometimes bugs out and
returns NULL. If wrapped in a NullPointerException these expected error
conditions could be caught at runtime, while any other errors would
continue to have their normal behaviour (such as triggering a
higher-scoped catch-all/default exception handler).

Regards,

Rowan Collins
[IMSoP]

10 years ago by Levi Morrison — view source

unread

Lars Strojny wrote (on 06/10/2014):
Hi Nikita,

[...]
As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as
well.
This was previously not possible due to limitations in the compiler
design.
I very much like the idea of making fatal errors exceptions, so: thumbs
up! Is there a way to introduce different exception classes for different
errors. E.g.

UndefinedMethodException for stdClass::method()

NullPointerException for null::method()

UndefinedFunctionException for invalid_function()

etc.

They could all extend EngineException to have a common base class but I am
sure we could find good abstractions for an exception inheritance tree.

What do you think?
It was suggested in the previous discussion that this could be added later,
but IMHO, it's a must. Part of the power of exceptions is that you can
selectively catch them when you know you can deal with the result.

Emitting a single EngineException will just encourage a kind of "pokemon
exception handling", because the only way to use it is in a generic
"something went wrong" handler. The semantics of that handler might be a bit
tidier than one for E_RECOVERABLE_ERROR, but there's not a lot of extra
power available.

As an example where a specific exception would be useful, but a generic one
would not, consider a fluent interface which sometimes bugs out and returns
NULL. If wrapped in a NullPointerException these expected error conditions
could be caught at runtime, while any other errors would continue to have
their normal behaviour (such as triggering a higher-scoped catch-all/default
exception handler).

I would contend that catching a NullPointerException is not any more
recoverable than most other EngineExceptions. I would also argue that
you should never, in any language, catch a NPE. The only time you
should catch an NPE is if you are catching all exceptions, such as in
a FastCGI daemon that will cleanly shutdown afterwards.

10 years ago by Rowan Collins — view source

unread

On Tue, Oct 7, 2014 at 7:58 AM, Rowan Collins rowan.collins@gmail.com
wrote:

As an example where a specific exception would be useful, but a
generic one
would not, consider a fluent interface which sometimes bugs out and
returns
NULL. If wrapped in a NullPointerException these expected error
conditions
could be caught at runtime, while any other errors would continue to
have
their normal behaviour (such as triggering a higher-scoped
catch-all/default
exception handler).

I would contend that catching a NullPointerException is not any more
recoverable than most other EngineExceptions.

In the scenario I just listed, the catch is effectively emulating an isset()/is_object() check before each chained operation. Seems perfectly reasonable to me. (If I'm not much mistaken, CoffeeScript has an operator for this precise case.)

I would also argue that
you should never, in any language, catch a NPE. The only time you
should catch an NPE is if you are catching all exceptions, such as in
a FastCGI daemon that will cleanly shutdown afterwards.

If you're not allowed to catch it, why make it an exception? Benefits such as unwinding finally blocks and destructors, and collecting backtraces, are secondary effects, not really fundamental to exceptions.

Perhaps "NullPointerException" is not a good name, as it has rather different implications than in other languages. In PHP, using the -> operator on a non-object isn't much different from calling a function with incorrect types. It shouldn't happen if your code is properly unit-tested, but it doesn't necessarily mean a catastrophic failure has occurred.

Regards,

Rowan Collins
[IMSoP]

10 years ago by Levi Morrison — view source

unread

I would also argue that
you should never, in any language, catch a NPE. The only time you
should catch an NPE is if you are catching all exceptions, such as in
a FastCGI daemon that will cleanly shutdown afterwards.

If you're not allowed to catch it, why make it an exception? Benefits such as unwinding finally blocks and destructors, and collecting backtraces, are secondary effects, not really fundamental to exceptions.

This is not a new idea; a very quick search turned up the CERT Oracle
Coding Standard for Java:

"Programs must not catch java.lang.NullPointerException. A
NullPointerException exception thrown at runtime indicates the
existence of an underlying null pointer dereference that must be fixed
in the application code[...] Handling the underlying null pointer
dereference by catching the NullPointerException rather than fixing
the underlying problem is inappropriate for several reasons."

I'll let you read the standard for the justification.

The point is that a few applications (and I mean a very few) need to
be able to handle these kinds of failures; for example a web server
shouldn't crash because the application throws a NullPointerException;
rather the worker dies and the client will be sent a 500 error and the
web server continues to run normally.

10 years ago by Rowan Collins — view source

unread

I would also argue that
you should never, in any language, catch a NPE. The only time you
should catch an NPE is if you are catching all exceptions, such as in
a FastCGI daemon that will cleanly shutdown afterwards.
If you're not allowed to catch it, why make it an exception? Benefits such as unwinding finally blocks and destructors, and collecting backtraces, are secondary effects, not really fundamental to exceptions.
This is not a new idea; a very quick search turned up the CERT Oracle
Coding Standard for Java:

"Programs must not catch java.lang.NullPointerException. A
NullPointerException exception thrown at runtime indicates the
existence of an underlying null pointer dereference that must be fixed
in the application code[...] Handling the underlying null pointer
dereference by catching the NullPointerException rather than fixing
the underlying problem is inappropriate for several reasons."

I'll let you read the standard for the justification.

Assuming you mean this (you forgot the link, so I searched the quote):
https://www.securecoding.cert.org/confluence/display/java/ERR08-J.+Do+not+catch+NullPointerException+or+any+of+its+ancestors

They give 3 reasons:

Performance overhead.
I have no idea whether this is true for PHP's implementation of
Exceptions, or for the scenario which I came up with earlier.
Inability to know which part of the try{} block initiated the error.
This is a fair point, although why it is more true of these exceptions
than any other, I'm not sure.
"programs rarely remain in an expected and usable state after a
|NullPointerException| has been thrown"
As mentioned earlier, PHP is not Java, and the closest to a "Null
Pointer" is actually "variable which you thought was going to be an
object but turned out to be a scalar or array". The situations that lead
to the exception are vastly different, so the chances of recoverability
aren't really generalisable from one to the other.

To clarify, this is the kind of code I was thinking of:

$result = DataSource::newInstance()
->select('foo')
->from('bar')
->with('baz') // WHAT IF THIS RETURNS FALSE?
->using('id')
->where('foo_name', $name)
->and('active', true)
->fetchArray();

There are two ways I know of for dealing with an error midway through a
chain like that:

Return a "Null Object", or an object which has been put into an error
state, so that all following calls are executed, but do nothing.
Throw an exception, so that the chain finishes early, and the calling
code knows an error has occurred.

If the library author has done neither of these, you will be faced with
a "call to a member-function on a non-object" error. Your only recourse
if you cannot / are unwilling to fix the library is to remove the
elegance of the fluent interface and check an intermediate variable with
is_object() or instanceOf on every line.

If that was an exception, then you, as the library consumer, could catch
it, just like you would catch a custom exception thrown by a more
conscientious library author.

The point is that a few applications (and I mean avery few) need to
be able to handle these kinds of failures; for example a web server
shouldn't crash because the application throws a NullPointerException;
rather the worker dies and the client will be sent a 500 error and the
web server continues to run normally.

Just to clarify, are you broadly in favour of Engine Exceptions, or
against the whole idea? Because this sounds like a call for something
completely separated from the userland notion of "Exception", and indeed
something that would rarely even be written in PHP rather than C in an
extension.

Regards,

--
Rowan Collins
[IMSoP]

10 years ago by Stas Malyshev — view source

unread

Hi!

As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.

I like this. Fatal errors and warnings were for a long time in different
leagues, and the need to handle them better produced E_RECOVERABLE_ERROR
which is a weird creature - like exception but not quite. I think PHP 7
is a good time to move to exceptions for real errors (as opposed to
informational messages like E_WARNING).

The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes. Should we allow
it or should be have hierarchy that separates user exceptions and engine
exceptions, and have catch(Exception) catch only the former.

However, I see in the RFC it does not remove all the errors. I think we
need to strive for having all the non-core errors except for out of
memory and timeout be converted. Are there ones that are problematic to
convert or it is just the question of time/effort?

About the long error message - I usually wouldn't recommend that but
maybe here is a good place for an ini setting, saying if we really want
to display the stack trace for uncaught exceptions? In many production
systems, wasting time to collect and then print the backtrace may not be
needed, and one-point message is enough. Many tools already have such
option (xdebug included) so maybe if we move to exceptions core may have
something like that too?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

10 years ago by Dan Ackroyd — view source

unread

Stas wrote:

The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes.

It's not clear why would that be an issue - can you specify what the
problem would be?

Also, if we changed catch(Exception $e) to not catch all exceptions,
than we would need to have another way of specifying that a catch
block should catch all exceptions. Which would involve either making
\Exception extend another even 'baser' Exception, or a hack to the
syntax e.g. something like:

catch($e) {
// Catch without Exception type catches all exceptions
// and confuses people.
}

cheers
Dan
Ack

Hi!
As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.
I like this. Fatal errors and warnings were for a long time in different
leagues, and the need to handle them better produced E_RECOVERABLE_ERROR
which is a weird creature - like exception but not quite. I think PHP 7
is a good time to move to exceptions for real errors (as opposed to
informational messages like E_WARNING).

The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes. Should we allow
it or should be have hierarchy that separates user exceptions and engine
exceptions, and have catch(Exception) catch only the former.

However, I see in the RFC it does not remove all the errors. I think we
need to strive for having all the non-core errors except for out of
memory and timeout be converted. Are there ones that are problematic to
convert or it is just the question of time/effort?

About the long error message - I usually wouldn't recommend that but
maybe here is a good place for an ini setting, saying if we really want
to display the stack trace for uncaught exceptions? In many production
systems, wasting time to collect and then print the backtrace may not be
needed, and one-point message is enough. Many tools already have such
option (xdebug included) so maybe if we move to exceptions core may have
something like that too?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

10 years ago by Ferenc Kovacs — view source

unread

Stas wrote:

The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes.

It's not clear why would that be an issue - can you specify what the
problem would be?

Also, if we changed catch(Exception $e) to not catch all exceptions,
than we would need to have another way of specifying that a catch
block should catch all exceptions. Which would involve either making
\Exception extend another even 'baser' Exception, or a hack to the
syntax e.g. something like:

catch($e) {
// Catch without Exception type catches all exceptions
// and confuses people.
}

we discussed this before on the mailing list, the problem would be that
currently the fatal errors will stop the execution and even recoverable
fatals for most people (when they don't have a global error handler defined
to handle it) and theoretically it is possible that some code exists out
there with Pokemon Exception Handling (
http://c2.com/cgi/wiki?PokemonExceptionHandling) where the code would
continue the execution and probably does some logically faulty operation
which previously was only prevented by the fatal error stopping the code.
this indeed assumes that the user already follow bad coding practices(Catch
them all) and code with (potential) fatal errors so there were a
disagreement if we could afford this BC or not.
Personally I think that it would be fine for a major version.

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

10 years ago by Christian Stoller — view source

unread

From: Dan Ackroyd [mailto:danack@basereality.com] ,Sent: Tuesday, October 07, 2014 10:55 AM

Stas wrote:

The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes.

It's not clear why would that be an issue - can you specify what the
problem would be?

Also, if we changed catch(Exception $e) to not catch all exceptions,
than we would need to have another way of specifying that a catch
block should catch all exceptions. Which would involve either making
\Exception extend another even 'baser' Exception, or a hack to the
syntax e.g. something like:

catch($e) {
// Catch without Exception type catches all exceptions
// and confuses people.
}

cheers
Dan
Ack

We could make EngineException to be parent of the base Exception class.
And, if it is technically possible, it must be forbidden to extend
EngineException directly in userland.

This is just an idea. It would be a little bit strange if Exception is
not the base exception class ;) but it makes sense, because EngineException
is an exception of all other exceptions ^^

Christian

10 years ago by Ferenc Kovacs — view source

unread

On Tue, Oct 7, 2014 at 11:51 AM, Christian Stoller stoller@leonex.de
wrote:

From: Dan Ackroyd [mailto:danack@basereality.com] ,Sent: Tuesday, October
07, 2014 10:55 AM

Stas wrote:

The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes.

It's not clear why would that be an issue - can you specify what the
problem would be?

Also, if we changed catch(Exception $e) to not catch all exceptions,
than we would need to have another way of specifying that a catch
block should catch all exceptions. Which would involve either making
\Exception extend another even 'baser' Exception, or a hack to the
syntax e.g. something like:

catch($e) {
// Catch without Exception type catches all exceptions
// and confuses people.
}

cheers
Dan
Ack

We could make EngineException to be parent of the base Exception class.
And, if it is technically possible, it must be forbidden to extend
EngineException directly in userland.

This is just an idea. It would be a little bit strange if Exception is
not the base exception class ;) but it makes sense, because EngineException
is an exception of all other exceptions ^^

Christian

yes, this was also suggested before, but that will be also a BC break for
those people already using the name of the new parent class (
https://github.com/search?l=php&q=EngineException&type=Code&utf8=%E2%9C%93
for example).
which can be still an ok decision, I'm just stating/repeating the pro/cons
as this was all discussed before.

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

10 years ago by Markus Fischer — view source

unread

yes, this was also suggested before, but that will be also a BC break for
those people already using the name of the new parent class (
https://github.com/search?l=php&q=EngineException&type=Code&utf8=%E2%9C%93
for example).
which can be still an ok decision, I'm just stating/repeating the pro/cons
as this was all discussed before.

It should be considered that most of the results of this links are using
namespaces, the minority doesn't. And those ask for trouble anyway,
IMHO, if they don't use any kind of namespacing (be it old PEAR
conventions or using real namespaces).

Markus

10 years ago by Stas Malyshev — view source

unread

Hi!

yes, this was also suggested before, but that will be also a BC break
for those people already using the name of the new parent class
(https://github.com/search?l=php&q=EngineException&type=Code&utf8=%E2%9C%93
for example).

This btw looks like a bigger issue (though many of them are namespaced).
Maybe we shoud do \PHP\EngineException?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

10 years ago by Nikita Popov — view source

unread

On Tue, Oct 7, 2014 at 1:07 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:

Hi!
As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as
well.
This was previously not possible due to limitations in the compiler
design.
I like this. Fatal errors and warnings were for a long time in different
leagues, and the need to handle them better produced E_RECOVERABLE_ERROR
which is a weird creature - like exception but not quite. I think PHP 7
is a good time to move to exceptions for real errors (as opposed to
informational messages like E_WARNING).

The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes. Should we allow
it or should be have hierarchy that separates user exceptions and engine
exceptions, and have catch(Exception) catch only the former.

There is precedent in other languages for having exceptions that are not
usually caught. Java has a Throwable interface, which is implemented by
Exceptions and Errors, where the latter are usually not supposed to be
caught. Python has a BaseException, which is extended by Exception and
SystemExit, GeneratorExit and KeyboardInterrupt, where the latter three are
not usually supposed to be caught.

I think that the decision whether or not we wish to introduce something
like this mainly depends on how we intend these EngineExceptions to be
used. If they are only supposed to be caught by top-level code to enable
graceful error handling (in particular for long running code) then it
probably makes sense to keep them outside the main exception hierarchy. If
on the other hand it's considered okay to catch them during normal program
execution, they should be normal exceptions.

However, I see in the RFC it does not remove all the errors. I think we
need to strive for having all the non-core errors except for out of
memory and timeout be converted. Are there ones that are problematic to
convert or it is just the question of time/effort?

There are a number of E_ERRORs that we cannot feasibly convert to
exceptions. I've analyzed this for the previous discussion and likely the
numbers are still about right: http://markmail.org/message/gfdczr6zpgzynid4
So a conservative estimate is that we can turn 85% of the E_ERROR
occurrences into exceptions. (This doesn't tell us anything about the
percentage of actually thrown errors though.)

And yes, it's also a question of time/effort. The hard part usually isn't
converting to exceptions, but updating all the tests that fail because of
it. I'd like to have good exception coverage by the time PHP 7 gets
released, but would prefer to do the porting incrementally (these huge
patches get stale very fast).

Nikita

10 years ago by Patrick Schaaf — view source

unread

Looking at the list of fatal errors Nikita classified as not suitable for
converting to exceptions, I'd like to take exception : ) with two of them:

I would love to be able to catch, at toplevel. with an error handler or
otherwise, both the memory limits exceeded and time limit exceeded cases.

These two safeguards, by themselves, are not instabilities, right? The
limits could be set a bit higher and everything would continue normally,
right?

What I would like to see, is that I can configure an "extra allowance" for
both of these limits, in php.ini - if that extra allowance is configured,
and the normal limit is reached, generate a recoverable / catchable error
and/or exception, and extend the respective limit (once) by the extra
allowance.

So, in practise, I would allow 2 more seconds, and 10 MB more memory, for
use in a global handler that gives nicer error message, backtrace,
non-white-http-500-response, or similar reaction.

best regards
Patrick

10 years ago by Dan Ackroyd — view source

unread

Patrick wrote:

I would love to be able to catch, at toplevel. with an error handler or
otherwise, both the memory limits exceeded and time limit exceeded cases.

+1, as the kids today say.

I don't think that it should require any new code - we already have
the ability to extend the memory limit dynamically:

ini_set('memory_limit', (ini_get('memory_limit')+1).'M');

And similarly for set_time_limit().

Having the ability to catch these types of errors and do whatever is
required to exit the program cleanly, is far superior to having a
fatal error.

cheers
Dan

10 years ago by Andrea Faulds — view source

unread

I would love to be able to catch, at toplevel. with an error handler or
otherwise, both the memory limits exceeded and time limit exceeded cases.

These two safeguards, by themselves, are not instabilities, right? The
limits could be set a bit higher and everything would continue normally,
right?

Both are problematic.

There’s no technical reason to prevent catching the exceeding of the time limit… but that means you can circumvent the time limit. That’s bad. Perhaps you could catch it and have a short window to output an error and die, though?

Memory limit catching would cause instability, though. That’s an error thrown during memory allocation. Things will break horribly if it just returns `NULL` and carries on, because let’s be realistic here, an awful lot of code doesn’t check for `NULL` return values. It’ll lead to a segfault. PHP must bail out immediately when this happens to prevent segfaulting.

Andrea Faulds
http://ajf.me/

10 years ago by Dmitry Stogov — view source

unread

Hi Nikita,

I very like the idea.
Actually, it's a long time desired php feature that many big php users miss.
They don't like to show 500 response in any case.

Also +1 for removing ability of silent E_RECOVERABLE_ERROR bypass :)

I think that few things may be "improved"

I'm not sure if "cacth(Exception $e)" should catch engine and parser
exceptions. May be it's better to introduce interface or common parent
class "Catchable" and then make Exception, EngineException and
ParseException implement it. In case user would like to catch all the error
at once they will able to use "catch(Catchable $e)", but cacth(Exception
$e) would be 100% compatible.
I also think it's not a big problem to keep compatible error messages
for uncaught EngineException and ParseException. I'm not sure if that
"Uncaught EngineException:" really need.

Thanks. Dmitry.

Hi internals!

During the PHP 5.6 development cycle I have proposed an RFC 1 that
suggested the use of exceptions instead of fatal errors in the engine. At
the time the proposal was declined, because the change was judged too
intrusive for a minor version.

As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.

Thanks,
Nikita

10 years ago by Stas Malyshev — view source

unread

Hi!

I'm not sure if "cacth(Exception $e)" should catch engine and parser
exceptions. May be it's better to introduce interface or common parent
class "Catchable" and then make Exception, EngineException and
ParseException implement it. In case user would like to catch all the error
at once they will able to use "catch(Catchable $e)", but cacth(Exception
$e) would be 100% compatible.

We had some requests for 'Throwable' class/interface for some time, e.g.:
https://bugs.php.net/bug.php?id=48599

Maybe we could borrow something from Java here
(http://docs.oracle.com/javase/6/docs/api/java/lang/Throwable.html) -
not sure if it's the best way but it's an option.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

10 years ago by Ralf Lang — view source

unread

Hi internals!

During the PHP 5.6 development cycle I have proposed an RFC [1] that
suggested the use of exceptions instead of fatal errors in the engine. At
the time the proposal was declined, because the change was judged too
intrusive for a minor version.

As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7

++

I very much like the change and have proposed something similar before.
A major version change is the best time to do it and it will be long
after php7 to see another one.

This would enable us to cleanup much weird userland code.

Just let's make sure to get it right this time.

--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

9 years ago by Nikita Popov — view source

unread

Hi internals!

During the PHP 5.6 development cycle I have proposed an RFC 1 that
suggested the use of exceptions instead of fatal errors in the engine. At
the time the proposal was declined, because the change was judged too
intrusive for a minor version.

As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.

Thanks,
Nikita

Feature freeze is not so far away now, so I'd like to bring this RFC up
again and proceed to voting shortly. There are two primary open questions:

Subclassing: Should there be more specific subclasses of EngineException
for particular errors?
Superclassing: Should EngineException inherit from Exception (and as
such be subject to catch(Exception)) or should we introduce some kind of
special super-class that is not caught by default (like
Catchable/Throwable)?

I don't think we can implement a high-quality subclassing scheme in a
timeframe for PHP 7, as such I would suggest to postpone this (if we
actually want to do it) to a later point in time. We can introduce
subclasses without BC issues in a minor version.

The question of whether EngineException should inherit from Exception is
something we do have to consider now. Personally I prefer not introducing
any special exception types that aren't caught by default. I think that
would only make sense for errors that could occur literally everywhere
(like memory limit or timeout), but these are not handled by this RFC for
technical reasons. If someone has a strong opinion on this, I might make it
a voting option.

Commentary on these, and also any other relevant points is very welcome!

Thanks,
Nikita

PS: The patch attached to the RFC is very outdated. I plan to only update
it to current master once the RFC passes (if it does), as I already had to
practically rewrite it a few times.

9 years ago by Benoit Schildknecht — view source

unread

Hi,

Le Sat, 14 Feb 2015 00:25:12 +0100, Nikita Popov nikita.ppv@gmail.com a
écrit:

The question of whether EngineException should inherit from Exception is
something we do have to consider now. Personally I prefer not introducing
any special exception types that aren't caught by default. I think that
would only make sense for errors that could occur literally everywhere
(like memory limit or timeout), but these are not handled by this RFC for
technical reasons. If someone has a strong opinion on this, I might make
it
a voting option.

Commentary on these, and also any other relevant points is very welcome!

Thanks,
Nikita

I don't think EngineException should inherit from Exception, it would be
very dangerous. I'm sure a lot of exceptions are handled like this by a
lot of devs, without creating custom exceptions :

try {

} catch ( Exception $e ) {

}

Making EngineException inherit from Exception means that there is a chance
it will change the behavior of this kind of code, maybe breaking some
crucial datas in database or such.

Instead, I think Exception should inherit from EngineException. Or
anything else.

Regards,
Benoit.

9 years ago by Leigh — view source

unread

I don't think EngineException should inherit from Exception, it would be
very dangerous. I'm sure a lot of exceptions are handled like this by a lot
of devs, without creating custom exceptions :

Agreed, EngineException should be a base type of it's own.

9 years ago by S.A.N — view source

unread

2015-02-14 2:38 GMT+02:00 Leigh leight@gmail.com:

I don't think EngineException should inherit from Exception, it would be
very dangerous. I'm sure a lot of exceptions are handled like this by a lot
of devs, without creating custom exceptions :

Agreed, EngineException should be a base type of it's own.

--

May be better: PHP\Exception?

9 years ago by Pierre Joye — view source

unread

Could you revive it in a new thread please? :)

On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita.ppv@gmail.com
wrote:
Hi internals!

During the PHP 5.6 development cycle I have proposed an RFC 1 that
suggested the use of exceptions instead of fatal errors in the engine. At
the time the proposal was declined, because the change was judged too
intrusive for a minor version.

As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as
well.
This was previously not possible due to limitations in the compiler
design.

Thanks,
Nikita
Feature freeze is not so far away now, so I'd like to bring this RFC up
again and proceed to voting shortly. There are two primary open questions:

Subclassing: Should there be more specific subclasses of EngineException
for particular errors?

Superclassing: Should EngineException inherit from Exception (and as
such be subject to catch(Exception)) or should we introduce some kind of
special super-class that is not caught by default (like
Catchable/Throwable)?

I don't think we can implement a high-quality subclassing scheme in a
timeframe for PHP 7, as such I would suggest to postpone this (if we
actually want to do it) to a later point in time. We can introduce
subclasses without BC issues in a minor version.

The question of whether EngineException should inherit from Exception is
something we do have to consider now. Personally I prefer not introducing
any special exception types that aren't caught by default. I think that
would only make sense for errors that could occur literally everywhere
(like memory limit or timeout), but these are not handled by this RFC for
technical reasons. If someone has a strong opinion on this, I might make it
a voting option.

Commentary on these, and also any other relevant points is very welcome!

Thanks,
Nikita

PS: The patch attached to the RFC is very outdated. I plan to only update
it to current master once the RFC passes (if it does), as I already had to
practically rewrite it a few times.

9 years ago by Bob Weinand — view source

unread

Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita.ppv@gmail.com:

Hi internals!

During the PHP 5.6 development cycle I have proposed an RFC 1 that
suggested the use of exceptions instead of fatal errors in the engine. At
the time the proposal was declined, because the change was judged too
intrusive for a minor version.

As such I'm re-proposing this RFC for inclusion in PHP 7:

https://wiki.php.net/rfc/engine_exceptions_for_php7

The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.

Thanks,
Nikita

Feature freeze is not so far away now, so I'd like to bring this RFC up
again and proceed to voting shortly. There are two primary open questions:

Subclassing: Should there be more specific subclasses of EngineException
for particular errors?

Superclassing: Should EngineException inherit from Exception (and as
such be subject to catch(Exception)) or should we introduce some kind of
special super-class that is not caught by default (like
Catchable/Throwable)?

I don't think we can implement a high-quality subclassing scheme in a
timeframe for PHP 7, as such I would suggest to postpone this (if we
actually want to do it) to a later point in time. We can introduce
subclasses without BC issues in a minor version.

The question of whether EngineException should inherit from Exception is
something we do have to consider now. Personally I prefer not introducing
any special exception types that aren't caught by default. I think that
would only make sense for errors that could occur literally everywhere
(like memory limit or timeout), but these are not handled by this RFC for
technical reasons. If someone has a strong opinion on this, I might make it
a voting option.

Commentary on these, and also any other relevant points is very welcome!

Thanks,
Nikita

PS: The patch attached to the RFC is very outdated. I plan to only update
it to current master once the RFC passes (if it does), as I already had to
practically rewrite it a few times.

Hey,

For subclassing I totally agree that we should postpone this (if we want this at all).

I think EngineException should inherit from Exception. You usually only catch Exception in catch-all handlers to display, log etc. the backtraces. In all these cases, you're very likely to want to catch the EngineException too, without a second catch block where the catch body is duplicated.
I can't really think of a catch-all block where you'd explicitly don't want to handle EngineException. And if it'd really be the case, you still can do an instanceof check and rethrow if needed...

Thanks,
Bob

9 years ago by Benjamin Eberlei — view source

unread

Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita.ppv@gmail.com:

On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita.ppv@gmail.com
wrote:

Hi internals!

During the PHP 5.6 development cycle I have proposed an RFC 1 that
suggested the use of exceptions instead of fatal errors in the engine.
At
the time the proposal was declined, because the change was judged too
intrusive for a minor version.

As such I'm re-proposing this RFC for inclusion in PHP 7:

https://wiki.php.net/rfc/engine_exceptions_for_php7

The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as
well.
This was previously not possible due to limitations in the compiler
design.

Thanks,
Nikita

Feature freeze is not so far away now, so I'd like to bring this RFC up
again and proceed to voting shortly. There are two primary open
questions:

Subclassing: Should there be more specific subclasses of
EngineException
for particular errors?

Superclassing: Should EngineException inherit from Exception (and as
such be subject to catch(Exception)) or should we introduce some kind of
special super-class that is not caught by default (like
Catchable/Throwable)?

I don't think we can implement a high-quality subclassing scheme in a
timeframe for PHP 7, as such I would suggest to postpone this (if we
actually want to do it) to a later point in time. We can introduce
subclasses without BC issues in a minor version.

The question of whether EngineException should inherit from Exception is
something we do have to consider now. Personally I prefer not introducing
any special exception types that aren't caught by default. I think that
would only make sense for errors that could occur literally everywhere
(like memory limit or timeout), but these are not handled by this RFC for
technical reasons. If someone has a strong opinion on this, I might make
it
a voting option.

Commentary on these, and also any other relevant points is very welcome!

Thanks,
Nikita

PS: The patch attached to the RFC is very outdated. I plan to only update
it to current master once the RFC passes (if it does), as I already had
to
practically rewrite it a few times.

Hey,

For subclassing I totally agree that we should postpone this (if we want
this at all).

I think EngineException should inherit from Exception. You usually only
catch Exception in catch-all handlers to display, log etc. the backtraces.
In all these cases, you're very likely to want to catch the EngineException
too, without a second catch block where the catch body is duplicated.
I can't really think of a catch-all block where you'd explicitly don't
want to handle EngineException. And if it'd really be the case, you still
can do an instanceof check and rethrow if needed...

I think that would be a huge BC break. I see a lot of code just catching
\Exception at various customers and opensource projects. EngineException
should not be a child of Exception.

Thanks,
Bob

9 years ago by Bob Weinand — view source

unread

Am 17.02.2015 um 11:21 schrieb Benjamin Eberlei kontakt@beberlei.de:

Am 14.02.2015 um 00:25 schrieb Nikita Popov <nikita.ppv@gmail.com mailto:nikita.ppv@gmail.com>:

Hi internals!

During the PHP 5.6 development cycle I have proposed an RFC [1] that
suggested the use of exceptions instead of fatal errors in the engine. At
the time the proposal was declined, because the change was judged too
intrusive for a minor version.

As such I'm re-proposing this RFC for inclusion in PHP 7:

https://wiki.php.net/rfc/engine_exceptions_for_php7 https://wiki.php.net/rfc/engine_exceptions_for_php7

The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.

Thanks,
Nikita

[1]: https://wiki.php.net/rfc/engine_exceptions https://wiki.php.net/rfc/engine_exceptions

Feature freeze is not so far away now, so I'd like to bring this RFC up
again and proceed to voting shortly. There are two primary open questions:

Subclassing: Should there be more specific subclasses of EngineException
for particular errors?

Superclassing: Should EngineException inherit from Exception (and as
such be subject to catch(Exception)) or should we introduce some kind of
special super-class that is not caught by default (like
Catchable/Throwable)?

I don't think we can implement a high-quality subclassing scheme in a
timeframe for PHP 7, as such I would suggest to postpone this (if we
actually want to do it) to a later point in time. We can introduce
subclasses without BC issues in a minor version.

The question of whether EngineException should inherit from Exception is
something we do have to consider now. Personally I prefer not introducing
any special exception types that aren't caught by default. I think that
would only make sense for errors that could occur literally everywhere
(like memory limit or timeout), but these are not handled by this RFC for
technical reasons. If someone has a strong opinion on this, I might make it
a voting option.

Commentary on these, and also any other relevant points is very welcome!

Thanks,
Nikita

PS: The patch attached to the RFC is very outdated. I plan to only update
it to current master once the RFC passes (if it does), as I already had to
practically rewrite it a few times.

Hey,

For subclassing I totally agree that we should postpone this (if we want this at all).

I think EngineException should inherit from Exception. You usually only catch Exception in catch-all handlers to display, log etc. the backtraces. In all these cases, you're very likely to want to catch the EngineException too, without a second catch block where the catch body is duplicated.
I can't really think of a catch-all block where you'd explicitly don't want to handle EngineException. And if it'd really be the case, you still can do an instanceof check and rethrow if needed...

I think that would be a huge BC break. I see a lot of code just catching \Exception at various customers and opensource projects. EngineException should not be a child of Exception.

Thanks,
Bob

No, it isn't a BC break. It would only affect broken things, which generate fatals as of now.
Working applications are not affected and that way it does not break BC.

So, I don't see any harm here in superclassing EngineException.

Bob

9 years ago by Dan Ackroyd — view source

unread

Subclassing: Should there be more specific subclasses of EngineException
for particular errors?

It's not obvious that any subclasses would be useful. However using
the code to specify the exact type of error, rather than having to
inspect the message would be good.

Should EngineException inherit from Exception (and as such be
subject to catch(Exception)) or should we introduce some kind
of special super-class that is not caught by default

Even ignoring the BC problem with having EngineExceptions extending
Exception, I think the EngineException needs to be in a different
hierarchy to Exception to be able to write reasonable code in the
future

Without having EngineException in a separate hierarchy of exceptions,
the code below will catch exceptions where the data is 'ok' but there
was a problem with the code, and continue to process items. This is
almost certainly not the correct behaviour when an EngineException has
been encountered.

interface Service {
function foo($item);
}

function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service->foo($item);
}
// Because $service can throw an Exception that is specific to the
// implementation we have to catch \Exception, unless we are going
// to list all possible implementation specific exception types here.
// That would be a subtle case of strong coupling, and when a new
// implementation is made the new exception type would need to
// be added here.
catch(\Exception $e) {
// item was not processable but PHP engine is OK.
$item->markAsErrored();
//Go on to process the next item
}
}
}

To avoid having EngineExceptions in a separate hierarchy, this
function could be converted to:

However that is bad as i)it's boiler plate to do the correct behaviour
ii) you have to remember to do that everywhere. Having to remember to
do the correct thing, is going to lead to people forgetting.

It will still be necessary to catch all types of Exception in a single
catch block i.e. at the top level of a script to prevent exceptions
being shown to the end user. This could be made easier by having a
common super class for Exception and EngineException. However having
one try block that is required to have multiple catch statements to
catch all different types of exception is not that much of a burden:

try {
runApp();
}
catch(EngineException $e) {
handleException($ee);
}
catch(Exception $e) {
handleException($e);
}

As that would be the only place it would be required to catch both types.

TL:DR EngineException needs to not extend Exception, whether we need a
super class is not as clear.

cheers
Dan

9 years ago by Dmitry Stogov — view source

unread

On Wed, Feb 18, 2015 at 10:30 PM, Dan Ackroyd danack@basereality.com
wrote:

Subclassing: Should there be more specific subclasses of EngineException
for particular errors?

It's not obvious that any subclasses would be useful. However using
the code to specify the exact type of error, rather than having to
inspect the message would be good.

Should EngineException inherit from Exception (and as such be
subject to catch(Exception)) or should we introduce some kind
of special super-class that is not caught by default

Even ignoring the BC problem with having EngineExceptions extending
Exception, I think the EngineException needs to be in a different
hierarchy to Exception to be able to write reasonable code in the
future

Without having EngineException in a separate hierarchy of exceptions,
the code below will catch exceptions where the data is 'ok' but there
was a problem with the code, and continue to process items. This is
almost certainly not the correct behaviour when an EngineException has
been encountered.

interface Service {
function foo($item);
}

function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service->foo($item);
}
// Because $service can throw an Exception that is specific to the
// implementation we have to catch \Exception, unless we are going
// to list all possible implementation specific exception types here.
// That would be a subtle case of strong coupling, and when a new
// implementation is made the new exception type would need to
// be added here.
catch(\Exception $e) {
// item was not processable but PHP engine is OK.
$item->markAsErrored();
//Go on to process the next item
}
}
}

To avoid having EngineExceptions in a separate hierarchy, this
function could be converted to:

function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service->foo($item);
}
catch(\EngineException $ee) {
//PHP engine is not stable - lets get out of here.
throw $ee; //or throw new ProcessException($ee)
}
catch(\Exception $e) {
$item->markAsErrored();
}
}
}

However that is bad as i)it's boiler plate to do the correct behaviour
ii) you have to remember to do that everywhere. Having to remember to
do the correct thing, is going to lead to people forgetting.

It will still be necessary to catch all types of Exception in a single
catch block i.e. at the top level of a script to prevent exceptions
being shown to the end user. This could be made easier by having a
common super class for Exception and EngineException. However having
one try block that is required to have multiple catch statements to
catch all different types of exception is not that much of a burden:

try {
runApp();
}
catch(EngineException $e) {
handleException($ee);
}
catch(Exception $e) {
handleException($e);
}

As that would be the only place it would be required to catch both types.

TL:DR EngineException needs to not extend Exception, whether we need a
super class is not as clear.

cheers
Dan

--

I think we may introduce the following hierarchy

abstarct class BaseException {
}
class Exception extends BaseException {
}
class EngineException extends BaseException {
}

the existing code that caught Exception is going to be unaffected.
New code may decide to catch engine exception in separate catch block
(using EngineException) or in single block (using BaseException)

Thanks. Dmitry.

9 years ago by Alexey Zakhlestin — view source

unread

I think we may introduce the following hierarchy

abstarct class BaseException {
}
class Exception extends BaseException {
}
class EngineException extends BaseException {
}

the existing code that caught Exception is going to be unaffected.
New code may decide to catch engine exception in separate catch block
(using EngineException) or in single block (using BaseException)

If I remember it correctly, BaseException was used by some real code out there.
But we can use _BaseException instead

--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc

9 years ago by Trevor Suarez — view source

unread

I think that structure makes sense Dmitry.

Though, just a bit on naming here (I know, its not a big deal, and naming
is hard, haha):

I think that naming the new parent exception something like "Throwable" or
"Catchable" (as Nikita previously suggested) would be a bit more concise in
meaning than "BaseException". You may not have even meant that name as a
formal proposal, but I figured I'd weigh in regardless. :P

Trevor

On Thu Feb 19 2015 at 4:55:38 AM Dmitry Stogov dmitry@zend.com wrote:

On Wed, Feb 18, 2015 at 10:30 PM, Dan Ackroyd danack@basereality.com
wrote:

Subclassing: Should there be more specific subclasses of
EngineException
for particular errors?

It's not obvious that any subclasses would be useful. However using
the code to specify the exact type of error, rather than having to
inspect the message would be good.

Should EngineException inherit from Exception (and as such be
subject to catch(Exception)) or should we introduce some kind
of special super-class that is not caught by default

Even ignoring the BC problem with having EngineExceptions extending
Exception, I think the EngineException needs to be in a different
hierarchy to Exception to be able to write reasonable code in the
future

Without having EngineException in a separate hierarchy of exceptions,
the code below will catch exceptions where the data is 'ok' but there
was a problem with the code, and continue to process items. This is
almost certainly not the correct behaviour when an EngineException has
been encountered.

interface Service {
function foo($item);
}

function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service->foo($item);
}
// Because $service can throw an Exception that is specific to the
// implementation we have to catch \Exception, unless we are going
// to list all possible implementation specific exception types here.
// That would be a subtle case of strong coupling, and when a new
// implementation is made the new exception type would need to
// be added here.
catch(\Exception $e) {
// item was not processable but PHP engine is OK.
$item->markAsErrored();
//Go on to process the next item
}
}
}

To avoid having EngineExceptions in a separate hierarchy, this
function could be converted to:

function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service->foo($item);
}
catch(\EngineException $ee) {
//PHP engine is not stable - lets get out of here.
throw $ee; //or throw new ProcessException($ee)
}
catch(\Exception $e) {
$item->markAsErrored();
}
}
}

However that is bad as i)it's boiler plate to do the correct behaviour
ii) you have to remember to do that everywhere. Having to remember to
do the correct thing, is going to lead to people forgetting.

It will still be necessary to catch all types of Exception in a single
catch block i.e. at the top level of a script to prevent exceptions
being shown to the end user. This could be made easier by having a
common super class for Exception and EngineException. However having
one try block that is required to have multiple catch statements to
catch all different types of exception is not that much of a burden:

try {
runApp();
}
catch(EngineException $e) {
handleException($ee);
}
catch(Exception $e) {
handleException($e);
}

As that would be the only place it would be required to catch both types.

TL:DR EngineException needs to not extend Exception, whether we need a
super class is not as clear.

cheers
Dan

--

I think we may introduce the following hierarchy

abstarct class BaseException {
}
class Exception extends BaseException {
}
class EngineException extends BaseException {
}

the existing code that caught Exception is going to be unaffected.
New code may decide to catch engine exception in separate catch block
(using EngineException) or in single block (using BaseException)

Thanks. Dmitry.

9 years ago by Dmitry Stogov — view source

unread

I think that structure makes sense Dmitry.

Though, just a bit on naming here (I know, its not a big deal, and naming
is hard, haha):

I think that naming the new parent exception something like "Throwable" or
"Catchable" (as Nikita previously suggested) would be a bit more concise in
meaning than "BaseException". You may not have even meant that name as a
formal proposal, but I figured I'd weigh in regardless. :P

We thought about "Throwable" or "Catchable" interface, but this change
would require more changes and will make more BC breaks.

Thanks. Dmitry.

Trevor

On Thu Feb 19 2015 at 4:55:38 AM Dmitry Stogov dmitry@zend.com wrote:

On Wed, Feb 18, 2015 at 10:30 PM, Dan Ackroyd danack@basereality.com
wrote:

On 13 February 2015 at 23:25, Nikita Popov nikita.ppv@gmail.com
wrote:

Subclassing: Should there be more specific subclasses of
EngineException
for particular errors?

It's not obvious that any subclasses would be useful. However using
the code to specify the exact type of error, rather than having to
inspect the message would be good.

Should EngineException inherit from Exception (and as such be
subject to catch(Exception)) or should we introduce some kind
of special super-class that is not caught by default

Even ignoring the BC problem with having EngineExceptions extending
Exception, I think the EngineException needs to be in a different
hierarchy to Exception to be able to write reasonable code in the
future

Without having EngineException in a separate hierarchy of exceptions,
the code below will catch exceptions where the data is 'ok' but there
was a problem with the code, and continue to process items. This is
almost certainly not the correct behaviour when an EngineException has
been encountered.

interface Service {
function foo($item);
}

function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service->foo($item);
}
// Because $service can throw an Exception that is specific to the
// implementation we have to catch \Exception, unless we are going
// to list all possible implementation specific exception types here.
// That would be a subtle case of strong coupling, and when a new
// implementation is made the new exception type would need to
// be added here.
catch(\Exception $e) {
// item was not processable but PHP engine is OK.
$item->markAsErrored();
//Go on to process the next item
}
}
}

To avoid having EngineExceptions in a separate hierarchy, this
function could be converted to:

function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service->foo($item);
}
catch(\EngineException $ee) {
//PHP engine is not stable - lets get out of here.
throw $ee; //or throw new ProcessException($ee)
}
catch(\Exception $e) {
$item->markAsErrored();
}
}
}

However that is bad as i)it's boiler plate to do the correct behaviour
ii) you have to remember to do that everywhere. Having to remember to
do the correct thing, is going to lead to people forgetting.

It will still be necessary to catch all types of Exception in a single
catch block i.e. at the top level of a script to prevent exceptions
being shown to the end user. This could be made easier by having a
common super class for Exception and EngineException. However having
one try block that is required to have multiple catch statements to
catch all different types of exception is not that much of a burden:

try {
runApp();
}
catch(EngineException $e) {
handleException($ee);
}
catch(Exception $e) {
handleException($e);
}

As that would be the only place it would be required to catch both
types.

TL:DR EngineException needs to not extend Exception, whether we need a
super class is not as clear.

cheers
Dan

--

I think we may introduce the following hierarchy

abstarct class BaseException {
}
class Exception extends BaseException {
}
class EngineException extends BaseException {
}

the existing code that caught Exception is going to be unaffected.
New code may decide to catch engine exception in separate catch block
(using EngineException) or in single block (using BaseException)

Thanks. Dmitry.

9 years ago by Yasuo Ohgaki — view source

unread

Hi all,

I think that naming the new parent exception something like "Throwable" or
"Catchable" (as Nikita previously suggested) would be a bit more concise in
meaning than "BaseException". You may not have even meant that name as a
formal proposal, but I figured I'd weigh in regardless. :P

I think they probably should use namespace...

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Dmitry Stogov — view source

unread

I'm not sure. Currently we don't use namespaces for core classes, but I
won't object to change this.
Nikita, what do you think?

Thanks. Dmitry.

Hi all,

I think that naming the new parent exception something like "Throwable" or
"Catchable" (as Nikita previously suggested) would be a bit more concise
in
meaning than "BaseException". You may not have even meant that name as a
formal proposal, but I figured I'd weigh in regardless. :P

I think they probably should use namespace...

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Yasuo Ohgaki — view source

unread

Hi Dmitry,

I'm not sure. Currently we don't use namespaces for core classes, but I
won't object to change this.
Nikita, what do you think?

Thanks. Dmitry.

Hi all,

I think that naming the new parent exception something like "Throwable"
or
"Catchable" (as Nikita previously suggested) would be a bit more concise
in
meaning than "BaseException". You may not have even meant that name as a
formal proposal, but I figured I'd weigh in regardless. :P

I think they probably should use namespace...

I meant users should use namespace to avoid namespace collisions...

We may introduce "PHP" namespace for us to use. I'm +1 for this.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by pajousek@gmail.com — view source

unread

Hi all,

I think that naming the new parent exception something like "Throwable" or
"Catchable" (as Nikita previously suggested) would be a bit more concise in
meaning than "BaseException". You may not have even meant that name as a
formal proposal, but I figured I'd weigh in regardless. :P

I think they probably should use namespace...

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Hello,

yes, finally introducing namespaces into PHP core stuff would
definitely be beneficial. Polluting the global namespace more and more
should be avoided.

I would gladly see something like this:
Php\Throwable

Php\Exception
Php\ParseException
Php\EngineException

Of course, the \Exception would need to be kept (maybe as an alias to
\Php\Exception?), for backwards compability.

Regards
Pavel Kouril

9 years ago by Dan Ackroyd — view source

unread

I think we may introduce the following hierarchy
the existing code that caught Exception is going to be unaffected.

We could do that. But it's not obviously correct, and ought to be
justified as to why it would be the correct thing to do.

The problem of people needing to catch every type of exception could
also be solved by using a common interface.

class EngineException implements ExceptionInterface {}
class Exception implements ExceptionInterface {}

try {
foo();
}
catch(ExceptionInterface $exception) {
//catches everything.
}

This avoids a requirement for all exceptions to extend from a common
base class. The interface for exceptions would be the current
Exception classes methods, excluding the constructor.

We thought about "Throwable" or "Catchable" interface, but this change
would require more changes and will make more BC breaks.

Please can you explain what those problems are?

cheers
Dan

9 years ago by Dmitry Stogov — view source

unread

Exception declares protected properties that may be used in child classes
directly.
This is not possible with interface.

Thanks. Dmitry.

I think we may introduce the following hierarchy
the existing code that caught Exception is going to be unaffected.

We could do that. But it's not obviously correct, and ought to be
justified as to why it would be the correct thing to do.

The problem of people needing to catch every type of exception could
also be solved by using a common interface.

class EngineException implements ExceptionInterface {}
class Exception implements ExceptionInterface {}

try {
foo();
}
catch(ExceptionInterface $exception) {
//catches everything.
}

This avoids a requirement for all exceptions to extend from a common
base class. The interface for exceptions would be the current
Exception classes methods, excluding the constructor.

We thought about "Throwable" or "Catchable" interface, but this change
would require more changes and will make more BC breaks.

Please can you explain what those problems are?

cheers
Dan

9 years ago by Dan Ackroyd — view source

unread

Exception declares protected properties that may be used in child classes
directly.
This is not possible with interface.

So, you're saying it's easier to implement?

That isn't a fantastic way of making a language design decision.

cheers
Dan

9 years ago by Dmitry Stogov — view source

unread

Exception declares protected properties that may be used in child classes
directly.
This is not possible with interface.

So, you're saying it's easier to implement?

That isn't a fantastic way of making a language design decision.

We don't design from scratch. We improve PHP for years, and we are tying to
do it with minimal breaks for our users. If we may keep compatibility, we
would prefer to keep it, instead of allying yet another pattern from a
modern book.

Dmitry.

cheers
Dan

9 years ago by Dan Ackroyd — view source

unread

we are tying to
do it with minimal breaks for our users. If we may keep compatibility, we
would prefer to keep it,

Yeah - you still haven't said why choosing to extend exception rather
than using an interface has fewer BC problems.

We thought about "Throwable" or "Catchable" interface, but this change would require more changes and will make more BC breaks.
Exception declares protected properties that may be used in child classes directly.

Any class that extends Exception currently will still behave as it
does before. The only change to the Exception class would be add the
interface to it's declaration. I can't see how this causes a BC break.

Please can you say what the BC break is if you think there is one.

cheers
Dan

9 years ago by Dmitry Stogov — view source

unread

Hi Nikita,

I refactored your implementation: https://github.com/php/php-src/pull/1095

I introduced a class hierarchy to minimize effect on existing code.
cacth (Exception $e) won't catch new types of exceptions.

BaseException (abstarct)
+- EngineException
+- ParaseException
+- Exception
+-ErrorException
+- all other exceptions

In case of uncaught Parse and EngineEexception PHP writes the compatible
error message.
I made it mainly to keep thousand PHPT tests unchanged.
If you like we may introduce an ini option that will lead to emitting of
"Uncaught Exception ... " with backtrace instead.

The internal API was changed a bit. e.g. EngineException are thrown from
zend_error(), if the error_code has E_EXCEPTION bit set.
So to change some error into exception now we should change
zend_error(E_ERROR,...) into zend_error(E_EXCEPTION|E_ERROR. ...)

All tests are passed.
I'm not sure about sapi/cli/tests/bug43177.phpt, because it started to fail
also in master.

We may need to replace E_RECOVERABLE_ERROR with E_ERROR and fix
corresponding tests.
Despite of this, I think the patch is good enough to be merged into master.

We may decide to convert more fatal errors later, but it shouldn't prevent
from putting RFC into vote.

Thoughts?

Thanks. Dmitry.

On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita.ppv@gmail.com
wrote:
Hi internals!

During the PHP 5.6 development cycle I have proposed an RFC 1 that
suggested the use of exceptions instead of fatal errors in the engine. At
the time the proposal was declined, because the change was judged too
intrusive for a minor version.

As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as
well.
This was previously not possible due to limitations in the compiler
design.

Thanks,
Nikita
Feature freeze is not so far away now, so I'd like to bring this RFC up
again and proceed to voting shortly. There are two primary open questions:

Subclassing: Should there be more specific subclasses of EngineException
for particular errors?

Superclassing: Should EngineException inherit from Exception (and as
such be subject to catch(Exception)) or should we introduce some kind of
special super-class that is not caught by default (like
Catchable/Throwable)?

I don't think we can implement a high-quality subclassing scheme in a
timeframe for PHP 7, as such I would suggest to postpone this (if we
actually want to do it) to a later point in time. We can introduce
subclasses without BC issues in a minor version.

The question of whether EngineException should inherit from Exception is
something we do have to consider now. Personally I prefer not introducing
any special exception types that aren't caught by default. I think that
would only make sense for errors that could occur literally everywhere
(like memory limit or timeout), but these are not handled by this RFC for
technical reasons. If someone has a strong opinion on this, I might make it
a voting option.

Commentary on these, and also any other relevant points is very welcome!

Thanks,
Nikita

PS: The patch attached to the RFC is very outdated. I plan to only update
it to current master once the RFC passes (if it does), as I already had to
practically rewrite it a few times.

9 years ago by Patrick Schaaf — view source

unread

One question just popped up in my mind: what happens if there is a global
error handler in place that rethrows errors as exceptions. I heard such a
thing suggested pretty often. If not parse errors and other engine errors
get thrown as exceptions and are unhandled as such, and that error handler
then throws them again - endless recursion?

just an idea, maybe not a problem, then sorry.

best regards
Patrick

9 years ago by Nikita Popov — view source

unread

Hi Nikita,

I refactored your implementation: https://github.com/php/php-src/pull/1095

I introduced a class hierarchy to minimize effect on existing code.
cacth (Exception $e) won't catch new types of exceptions.

BaseException (abstarct)
+- EngineException
+- ParaseException
+- Exception
+-ErrorException
+- all other exceptions

In case of uncaught Parse and EngineEexception PHP writes the compatible
error message.
I made it mainly to keep thousand PHPT tests unchanged.
If you like we may introduce an ini option that will lead to emitting of
"Uncaught Exception ... " with backtrace instead.

The internal API was changed a bit. e.g. EngineException are thrown from
zend_error(), if the error_code has E_EXCEPTION bit set.
So to change some error into exception now we should change
zend_error(E_ERROR,...) into zend_error(E_EXCEPTION|E_ERROR. ...)

All tests are passed.
I'm not sure about sapi/cli/tests/bug43177.phpt, because it started to
fail also in master.

We may need to replace E_RECOVERABLE_ERROR with E_ERROR and fix
corresponding tests.
Despite of this, I think the patch is good enough to be merged into master.

We may decide to convert more fatal errors later, but it shouldn't prevent
from putting RFC into vote.

Thoughts?

I've updated some minor points in the RFC to be consistent with the new
patch. The BaseException based hierarchy will be a separate vote 1. If
there are no further concerns I'd start voting on this RFC tomorrow.

One point wrt the patch: Do you think it would be hard to use a clean
shutdown on uncaught exceptions? This would make sure we don't forget to
free anything when throwing exceptions.

Nikita

9 years ago by Dmitry Stogov — view source

unread

Hi Nikita,

I refactored your implementation:
https://github.com/php/php-src/pull/1095

I introduced a class hierarchy to minimize effect on existing code.
cacth (Exception $e) won't catch new types of exceptions.

BaseException (abstarct)
+- EngineException
+- ParaseException
+- Exception
+-ErrorException
+- all other exceptions

In case of uncaught Parse and EngineEexception PHP writes the compatible
error message.
I made it mainly to keep thousand PHPT tests unchanged.
If you like we may introduce an ini option that will lead to emitting of
"Uncaught Exception ... " with backtrace instead.

The internal API was changed a bit. e.g. EngineException are thrown from
zend_error(), if the error_code has E_EXCEPTION bit set.
So to change some error into exception now we should change
zend_error(E_ERROR,...) into zend_error(E_EXCEPTION|E_ERROR. ...)

All tests are passed.
I'm not sure about sapi/cli/tests/bug43177.phpt, because it started to
fail also in master.

We may need to replace E_RECOVERABLE_ERROR with E_ERROR and fix
corresponding tests.
Despite of this, I think the patch is good enough to be merged into
master.

We may decide to convert more fatal errors later, but it shouldn't
prevent from putting RFC into vote.

Thoughts?

I've updated some minor points in the RFC to be consistent with the new
patch. The BaseException based hierarchy will be a separate vote 1. If
there are no further concerns I'd start voting on this RFC tomorrow.

Yeah, please do. You may also note, that currently we kept "Recoverable
Fatal Error" messages for some errors, that are not recoverable any more.
The error mesages and tests should be changed later. They kept unchanged to
make difference between important engine changes and obivious renaming.

One point wrt the patch: Do you think it would be hard to use a clean
shutdown on uncaught exceptions? This would make sure we don't forget to
free anything when throwing exceptions.

Good, point. I think it shoul work near out of the box.

Thanks. Dmitry.

Nikita

9 years ago by Marc Bennewitz — view source

unread

Hi Dimitry,

Am 19.02.2015 um 16:13 schrieb Dmitry Stogov:

Hi Nikita,

I refactored your implementation: https://github.com/php/php-src/pull/1095

I introduced a class hierarchy to minimize effect on existing code.
cacth (Exception $e) won't catch new types of exceptions.

BaseException (abstarct)
+- EngineException
+- ParaseException
+- Exception
+-ErrorException
+- all other exceptions
I really like this RFC and Exception hierarchy but one very small note:
The name of BaseException is a bit to misunderstanding to me as it
clashes with the old base exception named Exception, which is by the way
very often used as alias (use Exception as BaseExcepton).
I know this isn't a technical issue but it reduces readability a code.

What are your thoughts about the following names ?:

RootException
AbstractExcepton

<snip>

Marc

9 years ago by Xinchen Hui — view source

unread

Hey:

Hi Dimitry,

Am 19.02.2015 um 16:13 schrieb Dmitry Stogov:

Hi Nikita,

I refactored your implementation: https://github.com/php/php-src/pull/1095

I introduced a class hierarchy to minimize effect on existing code.
cacth (Exception $e) won't catch new types of exceptions.

BaseException (abstarct)
+- EngineException
+- ParaseException
+- Exception
+-ErrorException
+- all other exceptions

I really like this RFC and Exception hierarchy but one very small note:
The name of BaseException is a bit to misunderstanding to me as it clashes
with the old base exception named Exception, which is by the way very often
used as alias (use Exception as BaseExcepton).
I know this isn't a technical issue but it reduces readability a code.

What are your thoughts about the following names ?:

RootException
AbstractExcepton
+1 for AbstarctException.

thanks

<snip>

Marc

--

--
Xinchen Hui
@Laruence
http://www.laruence.com/

9 years ago by Anthony Ferrara — view source

unread

Nikita (and all),

Subclassing: Should there be more specific subclasses of EngineException
for particular errors?

I think there's an important case to be made here. I don't think every
error belongs having its own subclass, but there are at least a few
cases where it may make sense. This list is based off the current PR
(1095) and should be seen as incomplete :

Argument Mismatch (not passing required parameter, passing invalid
parameter, etc)
Parse Error (eval, etc) - note this appears to be implemented already
Methods On Non-Objects (call to a member function on null)
Call to undefined method (this should be a separate exception from ^^^)

I also think it may be worth while splitting out Class not found and
function not found exceptions into their own type, but not 100% sure.

Thanks

Anthony

9 years ago by Dmitry Stogov — view source

unread

On Thu, Feb 19, 2015 at 11:26 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:

Nikita (and all),

Subclassing: Should there be more specific subclasses of
EngineException
for particular errors?

I think there's an important case to be made here. I don't think every
error belongs having its own subclass, but there are at least a few
cases where it may make sense. This list is based off the current PR
(1095) and should be seen as incomplete :

Argument Mismatch (not passing required parameter, passing invalid
parameter, etc)

Parse Error (eval, etc) - note this appears to be implemented already

Methods On Non-Objects (call to a member function on null)

Call to undefined method (this should be a separate exception from ^^^)

I also think it may be worth while splitting out Class not found and
function not found exceptions into their own type, but not 100% sure.

Of course, we can add few subclasses of EngineException.

Thanks. Dmitry,

Thanks

Anthony

9 years ago by Yasuo Ohgaki — view source

unread

Hi Nikita,

As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.

Are E_WARNING, etc future scope?
I briefly looked the patch. It seems it covers only engine errors.
I suppose it's the scope of this RFC, though.
If API is made adoptable to modules for E_WARNING, etc, it would be
great.

Anyway, +1

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Nikita Popov — view source

unread

Hi Nikita,
As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as
well.
This was previously not possible due to limitations in the compiler
design.
Are E_WARNING, etc future scope?
I briefly looked the patch. It seems it covers only engine errors.
I suppose it's the scope of this RFC, though.
If API is made adoptable to modules for E_WARNING, etc, it would be
great.

This RFC is strictly about fatal and recoverable fatal errors. Changing any
other error types to exceptions would be a significant
backwards-compatibility break.

Nikita

Anyway, +1

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Rowan Collins — view source

unread

Hi Nikita,
As such I'm re-proposing this RFC for inclusion in PHP 7:
 https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.
Are E_WARNING, etc future scope?
I briefly looked the patch. It seems it covers only engine errors.
I suppose it's the scope of this RFC, though.
If API is made adoptable to modules for E_WARNING, etc, it would be
great.

Much though I'd love a more OO-approach to warnings, exceptions are not
an appropriate mechanism for that.

A rule of thumb I rather like is that you should only throw an exception
in a case where your best alternative, if it is not handled, is to call
die(). Clearly, E_ERROR meets this standard, and E_WARNING does not.

There has been much talk previously that "exceptions are great because
they include full backtraces", but there's no reason a new type of
warning object couldn't also include those, while retaining the key
characteristic of the default behaviour being to carry on with some
fallback value (an empty loop, a null variable, etc) rather than to
die('Uncaught Warning Exception!').

Regards,

--
Rowan Collins
[IMSoP]

9 years ago by Tony Marston — view source

unread

"Rowan Collins" wrote in message news:54E12349.7070806@gmail.com...

Hi Nikita,

On Tue, Oct 7, 2014 at 6:53 AM, Nikita Popov nikita.ppv@gmail.com
wrote:
As such I'm re-proposing this RFC for inclusion in PHP 7:
 https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as
well.
This was previously not possible due to limitations in the compiler
design.
Are E_WARNING, etc future scope?
I briefly looked the patch. It seems it covers only engine errors.
I suppose it's the scope of this RFC, though.
If API is made adoptable to modules for E_WARNING, etc, it would be
great.
Much though I'd love a more OO-approach to warnings, exceptions are not an
appropriate mechanism for that.

A rule of thumb I rather like is that you should only throw an exception in
a case where your best alternative, if it is not handled, is to call die().
Clearly, E_ERROR meets this standard, and E_WARNING does not.

There has been much talk previously that "exceptions are great because they
include full backtraces", but there's no reason a new type of warning
object couldn't also include those, while retaining the key characteristic
of the default behaviour being to carry on with some fallback value (an
empty loop, a null variable, etc) rather than to die('Uncaught Warning
Exception!').

Regards,

This RFC only mentions errors with object methods, so what impact would it
have with procedural functions. For example, if fopen('nonexistantfile.txt')
fails the return value is FALSE and an E_WARNING is generated, but it is
difficult to trap the error message (it could be a permissions error, for
example). Is there any plan to convert procedural functions to throw
exceptions?

--
Tony Marston

9 years ago by Rowan Collins — view source

unread

Tony Marston wrote on 16/02/2015 10:09:

This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message
(it could be a permissions error, for example). Is there any plan to
convert procedural functions to throw exceptions?

As Nikita already said:

This RFC is strictly about fatal and recoverable fatal errors. Changing any
other error types to exceptions would be a significant
backwards-compatibility break.

So, no, since that's currently an E_WARNING, there is no current plan to
change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications of
changing something from non-fatal to fatal are rather drastic.

That has absolutely nothing to do with OO vs procedural code, though. A
procedural function could well have an error condition which should be
fatal if unhandled, but can usefully be caught somewhere up the stack,
which is basically what an exception is for. Any procedural function
which currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate
to be converted under the current RFC.

Regards,

Rowan Collins
[IMSoP]

9 years ago by Tony Marston — view source

unread

"Rowan Collins" wrote in message news:54E1C993.1070609@gmail.com...

Tony Marston wrote on 16/02/2015 10:09:

This RFC only mentions errors with object methods, so what impact would
it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message (it
could be a permissions error, for example). Is there any plan to convert
procedural functions to throw exceptions?

As Nikita already said:

This RFC is strictly about fatal and recoverable fatal errors. Changing
any
other error types to exceptions would be a significant
backwards-compatibility break.

So, no, since that's currently an E_WARNING, there is no current plan to
change that case to an exception. If we were writing fopen() from scratch
now, it might be worth considering, but the BC implications of changing
something from non-fatal to fatal are rather drastic.

That has absolutely nothing to do with OO vs procedural code, though. A
procedural function could well have an error condition which should be
fatal if unhandled, but can usefully be caught somewhere up the stack,
which is basically what an exception is for. Any procedural function which
currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate to be
converted under the current RFC.

Regards,

The reason that I mentioned this problem with fopen() - the difficulty with
capturing the error message if it fails - is that it also exists with some
other functions as well, so it would be nice to be able to put the function
in a try ..... catch block so that any and every message could be made
available. It is quite obvious that changing fopen() to use exceptions would
be a major BC break for all exiting applications, so my question is this:

Would it be possible to tell the function if it were being called in a try
... catch bloc or not? If it were then throw an exception, if not then don't
throw an exception. I realise that this might be tricky to implement, but if
it could be it would allow the developer to choose whether he/she wanted to
use exceptions or not instead of having the choice forced upon him/her.

Is this possible? Or am I just dreaming?

--
Tony Marston

9 years ago by Rowan Collins — view source

unread

Tony Marston wrote on 17/02/2015 09:59:

"Rowan Collins" wrote in message news:54E1C993.1070609@gmail.com...

Tony Marston wrote on 16/02/2015 10:09:

This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error
message (it could be a permissions error, for example). Is there any
plan to convert procedural functions to throw exceptions?

As Nikita already said:

This RFC is strictly about fatal and recoverable fatal errors.
Changing any
other error types to exceptions would be a significant
backwards-compatibility break.

So, no, since that's currently an E_WARNING, there is no current plan
to change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications
of changing something from non-fatal to fatal are rather drastic.

That has absolutely nothing to do with OO vs procedural code, though.
A procedural function could well have an error condition which should
be fatal if unhandled, but can usefully be caught somewhere up the
stack, which is basically what an exception is for. Any procedural
function which currently issues an E_ERROR or E_RECOVERABLE_ERROR is
a candidate to be converted under the current RFC.

Regards,

The reason that I mentioned this problem with fopen() - the difficulty
with capturing the error message if it fails - is that it also exists
with some other functions as well, so it would be nice to be able to
put the function in a try ..... catch block so that any and every
message could be made available. It is quite obvious that changing
fopen() to use exceptions would be a major BC break for all exiting
applications, so my question is this:

Would it be possible to tell the function if it were being called in a
try ... catch bloc or not? If it were then throw an exception, if not
then don't throw an exception. I realise that this might be tricky to
implement, but if it could be it would allow the developer to choose
whether he/she wanted to use exceptions or not instead of having the
choice forced upon him/her.

Is this possible? Or am I just dreaming?

The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call "in a try ... catch block"
for the purposes of that check, or not? If putting try { ... } around an
entire application caused all calls to fopen(), in every library it
used, to stop returning false, you'd have exactly the same BC issue as
just changing it permanently.

function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}

function load_data() {
$fh = fopen(...);
...
}

So no, I'm afraid it's probably not possible.

Regards,

Rowan Collins
[IMSoP]

9 years ago by Tony Marston — view source

unread

"Rowan Collins" wrote in message news:54E32CAA.5030600@gmail.com...

Tony Marston wrote on 17/02/2015 09:59:

"Rowan Collins" wrote in message news:54E1C993.1070609@gmail.com...

Tony Marston wrote on 16/02/2015 10:09:

This RFC only mentions errors with object methods, so what impact would
it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message
(it could be a permissions error, for example). Is there any plan to
convert procedural functions to throw exceptions?

As Nikita already said:

This RFC is strictly about fatal and recoverable fatal errors. Changing
any
other error types to exceptions would be a significant
backwards-compatibility break.

So, no, since that's currently an E_WARNING, there is no current plan to
change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications of
changing something from non-fatal to fatal are rather drastic.

That has absolutely nothing to do with OO vs procedural code, though. A
procedural function could well have an error condition which should be
fatal if unhandled, but can usefully be caught somewhere up the stack,
which is basically what an exception is for. Any procedural function
which currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate
to be converted under the current RFC.

Regards,

The reason that I mentioned this problem with fopen() - the difficulty
with capturing the error message if it fails - is that it also exists
with some other functions as well, so it would be nice to be able to put
the function in a try ..... catch block so that any and every message
could be made available. It is quite obvious that changing fopen() to use
exceptions would be a major BC break for all exiting applications, so my
question is this:

Would it be possible to tell the function if it were being called in a
try ... catch bloc or not? If it were then throw an exception, if not
then don't throw an exception. I realise that this might be tricky to
implement, but if it could be it would allow the developer to choose
whether he/she wanted to use exceptions or not instead of having the
choice forced upon him/her.

Is this possible? Or am I just dreaming?

The point of exceptions is that they don't have to be caught in the current
scope. So is the below fopen() call "in a try ... catch block" for the
purposes of that check, or not? If putting try { ... } around an entire
application caused all calls to fopen(), in every library it used, to stop
returning false, you'd have exactly the same BC issue as just changing it
permanently.

function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}

function load_data() {
$fh = fopen(...);
...
}

So no, I'm afraid it's probably not possible.

Regards,

Could it be restricted to the current scope? In your example the call to
fopen() exists in the load_data() function and is not in a try ... catch
block within that function, so the fact that the call to load_data() is
within a try ... catch block should be irrelevant as it is in a different
scope.

--
Tony Marston

9 years ago by Nikita Nefedov — view source

unread

Could it be restricted to the current scope? In your example the call to
fopen() exists in the load_data() function and is not in a try ... catch
block within that function, so the fact that the call to load_data() is
within a try ... catch block should be irrelevant as it is in a different
scope.

Hi Tony,

This sounds very hacky. If you want exceptions with file/stream functions I
suggest you to find some open library out there that can handle your user
case or you can use SplFileObject.

9 years ago by Tony Marston — view source

unread

"Nikita Nefedov" wrote in message
news:CALuY8tjUq70eLkV-MbDi-fEXZvWTFi82zCNmWr7tmvpiES9=Pw@mail.gmail.com...

Could it be restricted to the current scope? In your example the call to
fopen() exists in the load_data() function and is not in a try ... catch
block within that function, so the fact that the call to load_data() is
within a try ... catch block should be irrelevant as it is in a different
scope.

Hi Tony,

This sounds very hacky.

You could say that every piece of code is a "hack" with the only difference
being that some hacks are ugly while others are beautiful.

If you want exceptions with file/stream functions I
suggest you to find some open library out there that can handle your user
case or you can use SplFileObject.

--
Tony Marston

9 years ago by Rowan Collins — view source

unread

Tony Marston wrote on 18/02/2015 10:52:

"Rowan Collins" wrote in message news:54E32CAA.5030600@gmail.com...

Tony Marston wrote on 17/02/2015 09:59:

"Rowan Collins" wrote in message news:54E1C993.1070609@gmail.com...

Tony Marston wrote on 16/02/2015 10:09:

This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and
an E_WARNING is generated, but it is difficult to trap the error
message (it could be a permissions error, for example). Is there
any plan to convert procedural functions to throw exceptions?

As Nikita already said:

This RFC is strictly about fatal and recoverable fatal errors.
Changing any
other error types to exceptions would be a significant
backwards-compatibility break.

So, no, since that's currently an E_WARNING, there is no current
plan to change that case to an exception. If we were writing
fopen() from scratch now, it might be worth considering, but the BC
implications of changing something from non-fatal to fatal are
rather drastic.

That has absolutely nothing to do with OO vs procedural code,
though. A procedural function could well have an error condition
which should be fatal if unhandled, but can usefully be caught
somewhere up the stack, which is basically what an exception is
for. Any procedural function which currently issues an E_ERROR or
E_RECOVERABLE_ERROR is a candidate to be converted under the
current RFC.

Regards,

The reason that I mentioned this problem with fopen() - the
difficulty with capturing the error message if it fails - is that it
also exists with some other functions as well, so it would be nice
to be able to put the function in a try ..... catch block so that
any and every message could be made available. It is quite obvious
that changing fopen() to use exceptions would be a major BC break
for all exiting applications, so my question is this:

Would it be possible to tell the function if it were being called in
a try ... catch bloc or not? If it were then throw an exception, if
not then don't throw an exception. I realise that this might be
tricky to implement, but if it could be it would allow the developer
to choose whether he/she wanted to use exceptions or not instead of
having the choice forced upon him/her.

Is this possible? Or am I just dreaming?

The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call "in a try ... catch
block" for the purposes of that check, or not? If putting try { ... }
around an entire application caused all calls to fopen(), in every
library it used, to stop returning false, you'd have exactly the same
BC issue as just changing it permanently.

function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}

function load_data() {
$fh = fopen(...);
...
}

So no, I'm afraid it's probably not possible.

Regards,

Could it be restricted to the current scope? In your example the call
to fopen() exists in the load_data() function and is not in a try ...
catch block within that function, so the fact that the call to
load_data() is within a try ... catch block should be irrelevant as it
is in a different scope.

If the exception is only thrown when the try - catch is in the same
scope, is there really much advantage to it being an exception? When
you're that close to the code, sticking an if ( $fh === false ) { ... }
around it really isn't that much different from catch(IOException $e) {
... }.

Having the problem be detectable in a higher scope is kind of the point
of exceptions.

Regards,

Rowan Collins
[IMSoP]

9 years ago by Tony Marston — view source

unread

"Rowan Collins" wrote in message news:54E4FAC2.7060200@gmail.com...

Tony Marston wrote on 18/02/2015 10:52:

"Rowan Collins" wrote in message news:54E32CAA.5030600@gmail.com...

Tony Marston wrote on 17/02/2015 09:59:

"Rowan Collins" wrote in message news:54E1C993.1070609@gmail.com...

Tony Marston wrote on 16/02/2015 10:09:

This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message
(it could be a permissions error, for example). Is there any plan to
convert procedural functions to throw exceptions?

As Nikita already said:

This RFC is strictly about fatal and recoverable fatal errors.
Changing any
other error types to exceptions would be a significant
backwards-compatibility break.

So, no, since that's currently an E_WARNING, there is no current plan
to change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications of
changing something from non-fatal to fatal are rather drastic.

That has absolutely nothing to do with OO vs procedural code, though.
A procedural function could well have an error condition which should
be fatal if unhandled, but can usefully be caught somewhere up the
stack, which is basically what an exception is for. Any procedural
function which currently issues an E_ERROR or E_RECOVERABLE_ERROR is a
candidate to be converted under the current RFC.

Regards,

The reason that I mentioned this problem with fopen() - the difficulty
with capturing the error message if it fails - is that it also exists
with some other functions as well, so it would be nice to be able to
put the function in a try ..... catch block so that any and every
message could be made available. It is quite obvious that changing
fopen() to use exceptions would be a major BC break for all exiting
applications, so my question is this:

Would it be possible to tell the function if it were being called in a
try ... catch bloc or not? If it were then throw an exception, if not
then don't throw an exception. I realise that this might be tricky to
implement, but if it could be it would allow the developer to choose
whether he/she wanted to use exceptions or not instead of having the
choice forced upon him/her.

Is this possible? Or am I just dreaming?

The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call "in a try ... catch block"
for the purposes of that check, or not? If putting try { ... } around an
entire application caused all calls to fopen(), in every library it
used, to stop returning false, you'd have exactly the same BC issue as
just changing it permanently.

function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}

function load_data() {
$fh = fopen(...);
...
}

So no, I'm afraid it's probably not possible.

Regards,

Could it be restricted to the current scope? In your example the call to
fopen() exists in the load_data() function and is not in a try ... catch
block within that function, so the fact that the call to load_data() is
within a try ... catch block should be irrelevant as it is in a different
scope.

If the exception is only thrown when the try - catch is in the same scope,
is there really much advantage to it being an exception? When you're that
close to the code, sticking an if ( $fh === false ) { ... } around it
really isn't that much different from catch(IOException $e) {

The advantage is that you can obtain the reason for the error. All that
happens with fopen() at the moment is that it returns FALSE which tells you
that it has failed, but it does not tell you why. This is a classic example
of the semipredicate problem for which exceptions were originally designed.

Having the problem be detectable in a higher scope is kind of the point of
exceptions.

So is the ability of catching an exception immediately it is thrown so that
you can obtain the error message. Having the ability to deal with an
exception at a higher level is only relevant if you don't deal with it
immediately, either by design or by accident.

--
Tony Marston

9 years ago by Dmitry Stogov — view source

unread

On Thu, Feb 19, 2015 at 12:03 PM, Tony Marston TonyMarston@hotmail.com
wrote:

"Rowan Collins" wrote in message news:54E4FAC2.7060200@gmail.com...

Tony Marston wrote on 18/02/2015 10:52:

"Rowan Collins" wrote in message news:54E32CAA.5030600@gmail.com...

Tony Marston wrote on 17/02/2015 09:59:

"Rowan Collins" wrote in message news:54E1C993.1070609@gmail.com...

Tony Marston wrote on 16/02/2015 10:09:

This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message (it
could be a permissions error, for example). Is there any plan to convert
procedural functions to throw exceptions?

As Nikita already said:

This RFC is strictly about fatal and recoverable fatal errors.

Changing any
other error types to exceptions would be a significant
backwards-compatibility break.

So, no, since that's currently an E_WARNING, there is no current plan
to change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications of
changing something from non-fatal to fatal are rather drastic.

That has absolutely nothing to do with OO vs procedural code, though.
A procedural function could well have an error condition which should be
fatal if unhandled, but can usefully be caught somewhere up the stack,
which is basically what an exception is for. Any procedural function which
currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate to be
converted under the current RFC.

Regards,

The reason that I mentioned this problem with fopen() - the difficulty
with capturing the error message if it fails - is that it also exists with
some other functions as well, so it would be nice to be able to put the
function in a try ..... catch block so that any and every message could be
made available. It is quite obvious that changing fopen() to use exceptions
would be a major BC break for all exiting applications, so my question is
this:

Would it be possible to tell the function if it were being called in a
try ... catch bloc or not? If it were then throw an exception, if not then
don't throw an exception. I realise that this might be tricky to implement,
but if it could be it would allow the developer to choose whether he/she
wanted to use exceptions or not instead of having the choice forced upon
him/her.

Is this possible? Or am I just dreaming?

The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call "in a try ... catch block" for
the purposes of that check, or not? If putting try { ... } around an entire
application caused all calls to fopen(), in every library it used, to stop
returning false, you'd have exactly the same BC issue as just changing it
permanently.

function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}

function load_data() {
$fh = fopen(...);
...
}

So no, I'm afraid it's probably not possible.

Regards,

Could it be restricted to the current scope? In your example the call to
fopen() exists in the load_data() function and is not in a try ... catch
block within that function, so the fact that the call to load_data() is
within a try ... catch block should be irrelevant as it is in a different
scope.

If the exception is only thrown when the try - catch is in the same
scope, is there really much advantage to it being an exception? When you're
that close to the code, sticking an if ( $fh === false ) { ... } around it
really isn't that much different from catch(IOException $e) {

The advantage is that you can obtain the reason for the error. All that
happens with fopen() at the moment is that it returns FALSE which tells you
that it has failed, but it does not tell you why. This is a classic example
of the semipredicate problem for which exceptions were originally designed.

The main advantage is the ability to catch FATAL errors that previously
leaded to script termination and 500 response.

Thanks. Dmitry.

Having the problem be detectable in a higher scope is kind of the point

of exceptions.

So is the ability of catching an exception immediately it is thrown so
that you can obtain the error message. Having the ability to deal with an
exception at a higher level is only relevant if you don't deal with it
immediately, either by design or by accident.

--
Tony Marston

9 years ago by Tony Marston — view source

unread

"Dmitry Stogov" wrote in message
news:CA+9eiLu634OpuXVT8NnwZwitqc=S4g8UbbMj+coB4nmQcPXRQQ@mail.gmail.com...

On Thu, Feb 19, 2015 at 12:03 PM, Tony Marston TonyMarston@hotmail.com
wrote:

"Rowan Collins" wrote in message news:54E4FAC2.7060200@gmail.com...

Tony Marston wrote on 18/02/2015 10:52:

"Rowan Collins" wrote in message news:54E32CAA.5030600@gmail.com...

Tony Marston wrote on 17/02/2015 09:59:

"Rowan Collins" wrote in message news:54E1C993.1070609@gmail.com...

Tony Marston wrote on 16/02/2015 10:09:

This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error
message (it
could be a permissions error, for example). Is there any plan to
convert
procedural functions to throw exceptions?

As Nikita already said:

This RFC is strictly about fatal and recoverable fatal errors.

Changing any
other error types to exceptions would be a significant
backwards-compatibility break.

That is why I suggested that those functions could be made to switch between
throwing an exception or not based on them being included within a try ...
catch block (or not)

So, no, since that's currently an E_WARNING, there is no current
plan
to change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications
of
changing something from non-fatal to fatal are rather drastic.

Currently the only values returned by fopen(), fwrite() and fclose()
indicate either success or failure, but not the reason for any failure.

That has absolutely nothing to do with OO vs procedural code,
though.

I disagree. Exceptions were originally invented to solve the semipredicate
problem which only exists with procedural functions, not object methods.
Many OO purists would like exceptions to be thrown everywhere, but this
would present a huge BC break. If it were possible get these functions to
throw an exception ONLY when they are included in a try ... catch block then
this would not break BC at all.

--
Tony Marston

A procedural function could well have an error condition which
should be
fatal if unhandled, but can usefully be caught somewhere up the
stack,
which is basically what an exception is for. Any procedural function
which
currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate to
be
converted under the current RFC.

Regards,

The reason that I mentioned this problem with fopen() - the
difficulty
with capturing the error message if it fails - is that it also exists
with
some other functions as well, so it would be nice to be able to put
the
function in a try ..... catch block so that any and every message
could be
made available. It is quite obvious that changing fopen() to use
exceptions
would be a major BC break for all exiting applications, so my
question is
this:

Would it be possible to tell the function if it were being called in
a
try ... catch bloc or not? If it were then throw an exception, if not
then
don't throw an exception. I realise that this might be tricky to
implement,
but if it could be it would allow the developer to choose whether
he/she
wanted to use exceptions or not instead of having the choice forced
upon
him/her.

Is this possible? Or am I just dreaming?

The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call "in a try ... catch block"
for
the purposes of that check, or not? If putting try { ... } around an
entire
application caused all calls to fopen(), in every library it used, to
stop
returning false, you'd have exactly the same BC issue as just changing
it
permanently.

function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}

function load_data() {
$fh = fopen(...);
...
}

So no, I'm afraid it's probably not possible.

Could it be restricted to the current scope? In your example the call
to
fopen() exists in the load_data() function and is not in a try ...
catch
block within that function, so the fact that the call to load_data()
is
within a try ... catch block should be irrelevant as it is in a
different
scope.

If the exception is only thrown when the try - catch is in the same
scope, is there really much advantage to it being an exception? When
you're
that close to the code, sticking an if ( $fh === false ) { ... } around
it
really isn't that much different from catch(IOException $e) {

The advantage is that you can obtain the reason for the error. All that
happens with fopen() at the moment is that it returns FALSE which tells
you
that it has failed, but it does not tell you why. This is a classic
example
of the semipredicate problem for which exceptions were originally
designed.

The main advantage is the ability to catch FATAL errors that previously
leaded to script termination and 500 response.

Thanks. Dmitry.

Having the problem be detectable in a higher scope is kind of the point

of exceptions.

So is the ability of catching an exception immediately it is thrown so
that you can obtain the error message. Having the ability to deal with an
exception at a higher level is only relevant if you don't deal with it
immediately, either by design or by accident.

--
Tony Marston

9 years ago by Nikita Nefedov — view source

unread

On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston TonyMarston@hotmail.com
wrote:

I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO purists would like exceptions to be thrown
everywhere, but this would present a huge BC break. If it were possible
get these functions to throw an exception ONLY when they are included in
a try ... catch block then this would not break BC at all.

Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...

When some function's result heavily depends on the context it makes said
function much harder to reason about. And creates mental overhead for
those who'll have to read the code with this function.

And again, if you need exceptions for fopen please consider using
SplFileObject.

9 years ago by Tony Marston — view source

unread

""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc...

On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston TonyMarston@hotmail.com
wrote:

I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO purists would like exceptions to be thrown
everywhere, but this would present a huge BC break. If it were possible
get these functions to throw an exception ONLY when they are included in
a try ... catch block then this would not break BC at all.

Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...

I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);

while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch (....) {
....
}

When some function's result heavily depends on the context it makes said
function much harder to reason about. And creates mental overhead for
those who'll have to read the code with this function.

And again, if you need exceptions for fopen please consider using
SplFileObject.

For file usage, yes. But are there any other procedural functions without an
Spl* alternative which would benefit from this technique?

--
Tony Marston

9 years ago by Pierre Joye — view source

unread

""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc...

On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston TonyMarston@hotmail.com
wrote:

I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO purists would like exceptions to be thrown
everywhere, but this would present a huge BC break. If it were possible get
these functions to throw an exception ONLY when they are included in a try
... catch block then this would not break BC at all.

Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...

I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);

while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch (....) {
   ....
}

When some function's result heavily depends on the context it makes said
function much harder to reason about. And creates mental overhead for those
who'll have to read the code with this function.

And again, if you need exceptions for fopen please consider using
SplFileObject.

For file usage, yes. But are there any other procedural functions without
an Spl* alternative which would benefit from this technique?

Expected failures should not raise exception. For example, IOs are expected
to fail (be network, filesystem etc), I would really not be in favor of
adding exceptions for similar cases. This is a normal control flow.

9 years ago by Tony Marston — view source

unread

"Pierre Joye" wrote in message
news:CAEZPtU7vt=PpK4p3VFZFLAEPzi_wfr2Hr_av+dtzVD6D2dZCSw@mail.gmail.com...

""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc...

On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston
TonyMarston@hotmail.com
wrote:

I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO purists would like exceptions to be thrown
everywhere, but this would present a huge BC break. If it were possible get
these functions to throw an exception ONLY when they are included in a try
... catch block then this would not break BC at all.

Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...

I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);

while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch (....) {
   ....
}

When some function's result heavily depends on the context it makes said
function much harder to reason about. And creates mental overhead for those
who'll have to read the code with this function.

And again, if you need exceptions for fopen please consider using
SplFileObject.

For file usage, yes. But are there any other procedural functions without
an Spl* alternative which would benefit from this technique?
Expected failures should not raise exception. For example, IOs are expected
to fail (be network, filesystem etc), I would really not be in favor of
adding exceptions for similar cases. This is a normal control flow.
"Pierre Joye" wrote in message
news:CAEZPtU7vt=PpK4p3VFZFLAEPzi_wfr2Hr_av+dtzVD6D2dZCSw@mail.gmail.com...
""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc...

On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston
TonyMarston@hotmail.com
wrote:

I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO purists would like exceptions to be thrown
everywhere, but this would present a huge BC break. If it were possible get
these functions to throw an exception ONLY when they are included in a try
... catch block then this would not break BC at all.

Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...

I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);

while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch (....) {
   ....
}

When some function's result heavily depends on the context it makes said
function much harder to reason about. And creates mental overhead for those
who'll have to read the code with this function.

And again, if you need exceptions for fopen please consider using
SplFileObject.

For file usage, yes. But are there any other procedural functions without
an Spl* alternative which would benefit from this technique?
Expected failures should not raise exception. For example, IOs are expected
to fail (be network, filesystem etc), I would really not be in favor of
adding exceptions for similar cases. This is a normal control flow.

Then why do SplFileInfo::openFile and SplFileObject::__construct throw
exceptions if the file cannot be opened?

--
Tony Marston

9 years ago by Rowan Collins — view source

unread

Tony Marston wrote on 21/02/2015 10:08:

""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc...

On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston
TonyMarston@hotmail.com wrote:

I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions,
not object methods. Many OO purists would like exceptions to be
thrown everywhere, but this would present a huge BC break. If it
were possible get these functions to throw an exception ONLY when
they are included in a try ... catch block then this would not break
BC at all.

Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...

I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);

while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch (....) {
....
}

But what about this code, which could well already exist:

try {
    $fh = fopen(...);
    $this->processLotsOfDataAndMaybeThrowAnException($fh);
    fclose($fh);
} catch (....) {
    ....
}

If fopen() starts throwing exceptions here, that's as much a BC break as
it throwing them everywhere. If it doesn't, the rules for when it should
throw become even more complicated, and useful in even fewer cases.

Regards,

Rowan Collins
[IMSoP]

9 years ago by Lester Caine — view source

unread

Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...

I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);

while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch (....) {
....
}

But what about this code, which could well already exist:

try {
$fh = fopen(...);
$this->processLotsOfDataAndMaybeThrowAnException($fh);
fclose($fh);
} catch (....) {
....
}

If fopen() starts throwing exceptions here, that's as much a BC break as
it throwing them everywhere. If it doesn't, the rules for when it should
throw become even more complicated, and useful in even fewer cases.

That is certainly the sort of scenario that I am concerned about.
try/catch blocks have been added through a lot of libraries and if the
returns now change then currently working code starts to fail. Fixing
the extra exceptions looks more interesting, so referring to the first
try block above, having to catch different exceptions from each function
is the problem here. But I still prefer dealing with the error as part
of the function call so I can at least respond in the same context.

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

9 years ago by Dmitry Stogov — view source

unread

On Wed, Feb 25, 2015 at 4:19 PM, Rowan Collins rowan.collins@gmail.com
wrote:

Tony Marston wrote on 21/02/2015 10:08:

""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc...

On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston <
TonyMarston@hotmail.com> wrote:

I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO purists would like exceptions to be thrown
everywhere, but this would present a huge BC break. If it were possible get
these functions to throw an exception ONLY when they are included in a try
... catch block then this would not break BC at all.

Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...

I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);

while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch (....) {
....
}

But what about this code, which could well already exist:

try {
$fh = fopen(...);
$this->processLotsOfDataAndMaybeThrowAnException($fh);
fclose($fh);
} catch (....) {
....
}

If fopen() starts throwing exceptions here, that's as much a BC break as
it throwing them everywhere. If it doesn't, the rules for when it should
throw become even more complicated, and useful in even fewer cases.

No. The proposal is only about fatal engine errors, like "Fatal Error: Call
to undefined function %s()".
Instead of script termination they will throw exceptions.
fopen() won't be touched at all. It's out of scope of proposal.

Thanks. Dmitry.

Regards,

Rowan Collins
[IMSoP]

9 years ago by Rowan Collins — view source

unread

Dmitry Stogov wrote on 25/02/2015 14:07:

No. The proposal is only about fatal engine errors, like "Fatal Error:
Call to undefined function %s()".
Instead of script termination they will throw exceptions.
fopen() won't be touched at all. It's out of scope of proposal.

Hi Dmitry,

I was responding to a sub-thread where Tony Marston was requesting it be
extended to other scenarios, and explaining why the idea of changing
behaviour based on context would not work.

I agree that the current proposal, for fatal errors only, does not
constitute a significant BC break, particularly if the BaseException
superclass is added.

Regards,

Rowan Collins
[IMSoP]

9 years ago by Jonathan Wage — view source

unread

I am not familiar with the implementation details but from my perspective
this would be a nice improvement. I have had a difficult time debugging PHP
fatal errors over the years and I think this kind of change would help
improve that.

Hi internals!

During the PHP 5.6 development cycle I have proposed an RFC 1 that
suggested the use of exceptions instead of fatal errors in the engine. At
the time the proposal was declined, because the change was judged too
intrusive for a minor version.

As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.

Thanks,
Nikita

--
Connect with me on http://twitter.com/jwage <http://twitter.com/jwage

9 years ago by Robert Stoll — view source

unread

Hi Nikita

-----Ursprüngliche Nachricht-----
Von: Nikita Popov [mailto:nikita.ppv@gmail.com]
Gesendet: Montag, 6. Oktober 2014 23:54
An: PHP internals
Betreff: [PHP-DEV] [RFC] Exceptions in the engine

Hi internals!

During the PHP 5.6 development cycle I have proposed an RFC 1 that suggested the use of exceptions instead of fatal
errors in the engine. At the time the proposal was declined, because the change was judged too intrusive for a minor
version.

As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to
exceptions as well.
This was previously not possible due to limitations in the compiler design.

Thanks,
Nikita

Sorry, I am a little bit late with this one and I think it should not obstruct the vote in any way.

Will it be possible for a user to instantiate the new Exception classes?

Cheers,
Robert

[RFC] Exceptions in the engine

Regards,

Regards,

Regards,

Regards,

Regards,

Regards,

-- Lester Caine - G8HFL

Regards,

Regards,

--
Lester Caine - G8HFL