Hi Levi,
On Tue, Dec 6, 2016 at 12:15 PM, Levi Morrison <le...@php.net> wrote:
> On Mon, Dec 5, 2016 at 8:02 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>> Hi Levi,
>>
>> On Tue, Dec 6, 2016 at 11:52 AM, Levi Morrison <le...@php.net> wrote:
>>>>> These are not consistent with return type checking. This *must* reuse
>>>>> the error checking that is already in-place and not provide something
>>>>> new to accomplish the same thing.
>>>>
>>>> What do you mean by inconsistent?
>>>
>>> We do not use E_RECOVERABLE_ERROR for return type mismatches; we use
>>> TypeError. That is the inconsistency.
>>
>> It depends. Session module uses errors rather than exceptions. Mixing
>> them is inconsistent for a module.
>>
>> I wrote I prefer exceptions and I'll handle error handling issue
>> (error -> exception) with other RFC during discussion. So don't worry
>> about it for now.
>
> Currently all return types use TypeError when they do not match. Do
> not introduce anything different; we do not need any more special
> cases than we already have.
Error handling is out of scope of this RFC. It will be handled by other RFC.
Others requested "minimal" and "single scope" RFC to me. I don't mind
much to replace error to exception, since I'm going to do this anyway.
> Currently all return types use TypeError when they do not match.
It's irrelevant for this RFC, but it seems not many features uses
TypeError now. It seems only Zend is using TypeError.
$ find . -name '*.c' | xargs grep -n zend_ce_type_error
./Zend/zend_closures.c:330:
zend_throw_exception_ex(zend_ce_type_error, 0, "Failed to create
closure from callable: %s", error);
./Zend/zend_closures.c:333:
zend_throw_exception_ex(zend_ce_type_error, 0, "Failed to create
closure from callable");
./Zend/zend_API.c:256: zend_throw_error(zend_ce_type_error, "%s%s%s()
expects parameter %d to be a valid callback, %s",
./Zend/zend_exceptions.c:38:ZEND_API zend_class_entry *zend_ce_type_error;
./Zend/zend_exceptions.c:715: if ((Z_OBJCE_P(exception) ==
zend_ce_type_error || Z_OBJCE_P(exception) ==
zend_ce_argument_count_error) && strstr(ZSTR_VAL(message), ", called
in ")) {
./Zend/zend_exceptions.c:877: zend_ce_type_error =
zend_register_internal_class_ex(&ce, zend_ce_error);
./Zend/zend_exceptions.c:878: zend_ce_type_error->create_object =
zend_default_exception_new;
./Zend/zend_exceptions.c:881: zend_ce_argument_count_error =
zend_register_internal_class_ex(&ce, zend_ce_type_error);
./Zend/zend.c:1363: zend_throw_exception(zend_ce_type_error, message, 0);
./Zend/zend.c:1376: zend_throw_exception(zend_ce_type_error, message, 0);
I'm willing to adopt exceptions. Not only Zend, but also SPL defines
exceptions. I think we are better to have general guideline how we
should use exceptions to avoid needless exception usage inconsistency.
This is out of scope of this RFC clearly.
e.g. Invalid encode()/decode() return type could be
spl_ce_RuntimeException instead of zend_ce_type_error.
zend_ce_type_error could be reserved only for Zend, for example.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
