On Fri, Feb 20, 2015 at 8:01 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez 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
Hey:
On Tue, Feb 24, 2015 at 2:27 AM, Marc Bennewitz 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.
>
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
On Feb 22, 2015 9:25 PM, "Nikita Popov" wrote:
>
> On Thu, Feb 19, 2015 at 4:13 PM, Dmitry Stogov 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
On Thu, Feb 19, 2015 at 4:13 PM, Dmitry Stogov 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.
>
> BaseException (
Hi Dmitry,
On Fri, Feb 20, 2015 at 4:15 PM, Dmitry Stogov 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 wrote:
>
>> Hi all,
>>
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 wrote:
> Hi all,
>
> On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez wrote:
>
>> I think that naming th
Hi all,
On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez 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 as a
> f
On Thu, Feb 19, 2015 at 11:26 PM, Anthony Ferrara
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 sub
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 l
On 19 February 2015 at 16:25, Dmitry Stogov 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 problems.
> We
On Thu, Feb 19, 2015 at 7:06 PM, Dan Ackroyd wrote:
> On 19 February 2015 at 15:46, Dmitry Stogov 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 i
On 19 February 2015 at 15:46, Dmitry Stogov 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 decision.
cheers
D
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 wrote:
> On 19 February 2015 at 09:54, Dmitry Stogov wrote:
>
> > I think we may introduce the following hierarc
On 19 February 2015 at 09:54, Dmitry Stogov 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 thing to do.
T
On Thu, Feb 19, 2015 at 6:14 PM, Trevor Suarez 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 Nikit
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
th
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
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 Wed, Feb 18, 2015 at 10:30 PM, Dan Ackroyd
wrote:
> On 13 February 2015 at 23:25, Nikita Popov 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 s
On 13 February 2015 at 23:25, Nikita Popov 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
Could you revive it in a new thread please? :)
On Feb 13, 2015 3:25 PM, "Nikita Popov" wrote:
> On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov
> wrote:
>
> > Hi internals!
> >
> > During the PHP 5.6 development cycle I have proposed an RFC [1] that
> > suggested the use of exceptions instead of f
2015-02-14 2:38 GMT+02:00 Leigh :
> On 14 February 2015 at 00:32, Benoit Schildknecht 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 :
>
On 14 February 2015 at 00:32, Benoit Schildknecht 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 should be a b
24 matches
Mail list logo
