Hey:
On Tue, Feb 24, 2015 at 2:27 AM, Marc Bennewitz dev@mabe.berlin wrote:
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.
On Fri, Feb 20, 2015 at 8:01 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez ric...@gmail.com wrote:
I think that naming the new parent exception something like Throwable or
Catchable (as Nikita previously suggested) would be a bit more
On Feb 22, 2015 9:25 PM, Nikita Popov nikita@gmail.com wrote:
On Thu, Feb 19, 2015 at 4:13 PM, Dmitry Stogov dmi...@zend.com wrote:
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.
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
On Thu, Feb 19, 2015 at 4:13 PM, Dmitry Stogov dmi...@zend.com wrote:
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.
Hi Dmitry,
On Fri, Feb 20, 2015 at 4:15 PM, Dmitry Stogov dmi...@zend.com wrote:
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.
On Fri, Feb 20, 2015 at 10:01 AM, Yasuo Ohgaki
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
On Wed, Feb 18, 2015 at 10:30 PM, Dan Ackroyd dan...@basereality.com
wrote:
On 13 February 2015 at 23:25, Nikita Popov nikita@gmail.com wrote:
Subclassing: Should there be more specific subclasses of EngineException
for particular errors?
It's not obvious that any subclasses would be
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
On Thu, Feb 19, 2015 at 6:14 PM, Trevor Suarez ric...@gmail.com wrote:
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
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
On 19 February 2015 at 09:54, Dmitry Stogov dmi...@zend.com wrote:
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
Exception declares protected properties that may be used in child classes
directly.
This is not possible with interface.
Thanks. Dmitry.
On Thu, Feb 19, 2015 at 6:31 PM, Dan Ackroyd dan...@basereality.com wrote:
On 19 February 2015 at 09:54, Dmitry Stogov dmi...@zend.com wrote:
I think we
On Thu, Feb 19, 2015 at 11:26 PM, Anthony Ferrara ircmax...@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
Hi all,
On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez ric...@gmail.com wrote:
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
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.
On Fri, Feb 20, 2015 at 10:01 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez ric...@gmail.com
On Thu, Feb 19, 2015 at 7:06 PM, Dan Ackroyd dan...@basereality.com wrote:
On 19 February 2015 at 15:46, Dmitry Stogov dmi...@zend.com wrote:
Exception declares protected properties that may be used in child classes
directly.
This is not possible with interface.
So, you're saying it's
On 19 February 2015 at 16:25, Dmitry Stogov dmi...@zend.com wrote:
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
On 19 February 2015 at 15:46, Dmitry Stogov dmi...@zend.com wrote:
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
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
On 13 February 2015 at 23:25, Nikita Popov nikita@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
On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@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
2015-02-14 2:38 GMT+02:00 Leigh lei...@gmail.com:
On 14 February 2015 at 00:32, Benoit Schildknecht bensor...@neuf.fr wrote:
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
On 14 February 2015 at 00:32, Benoit Schildknecht bensor...@neuf.fr wrote:
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
Could you revive it in a new thread please? :)
On Feb 13, 2015 3:25 PM, Nikita Popov nikita@gmail.com wrote:
On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@gmail.com
wrote:
Hi internals!
During the PHP 5.6 development cycle I have proposed an RFC [1] that
suggested the
Hi,
Le Sat, 14 Feb 2015 00:25:12 +0100, Nikita Popov nikita@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
Okay that's reasonable enough ... Baby steps :)
Cheers
Joe
On 24 Oct 2013 20:40, Nikita Popov nikita@gmail.com wrote:
On Thu, Oct 24, 2013 at 9:27 PM, Joe Watkins krak...@php.net wrote:
I have to ask the question; why stop at half way ??
A warning does absolutely nothing for the
On 10/24/2013 06:41 PM, Nikita Popov wrote:
Hi internals!
I'd like to propose an RFC, which allows the use of exceptions within the
engine and also allows changing existing fatal errors to exceptions:
https://wiki.php.net/rfc/engine_exceptions
This topic has been cropping up in the
28 matches
Mail list logo
