Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:97302 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58277 invoked from network); 6 Dec 2016 03:42:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Dec 2016 03:42:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@ohgaki.net; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@ohgaki.net; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender) X-PHP-List-Original-Sender: yohgaki@ohgaki.net X-Host-Fingerprint: 180.42.98.130 ns1.es-i.jp Received: from [180.42.98.130] ([180.42.98.130:55000] helo=es-i.jp) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E5/2B-11772-99336485 for ; Mon, 05 Dec 2016 22:42:24 -0500 Received: (qmail 101937 invoked by uid 89); 6 Dec 2016 03:42:14 -0000 Received: from unknown (HELO mail-wm0-f54.google.com) (yohgaki@ohgaki.net@74.125.82.54) by 0 with ESMTPA; 6 Dec 2016 03:42:14 -0000 Received: by mail-wm0-f54.google.com with SMTP id c184so24240755wmd.0 for ; Mon, 05 Dec 2016 19:42:13 -0800 (PST) X-Gm-Message-State: AKaTC03Y/X8EuFjx1FhixqHNdk9wFXy9pfg2xXA2CVQgtej5ONwspd27BMzvmvqCfxP5gfAUXQ5FZ280y/21oQ== X-Received: by 10.28.174.76 with SMTP id x73mr674536wme.25.1480995727214; Mon, 05 Dec 2016 19:42:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.38.7 with HTTP; Mon, 5 Dec 2016 19:41:26 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Dec 2016 12:41:26 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Levi Morrison Cc: "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC][VOTE] User defined session serializer From: yohgaki@ohgaki.net (Yasuo Ohgaki) Hi Levi, On Tue, Dec 6, 2016 at 12:15 PM, Levi Morrison wrote: > On Mon, Dec 5, 2016 at 8:02 PM, Yasuo Ohgaki wrote: >> Hi Levi, >> >> On Tue, Dec 6, 2016 at 11:52 AM, Levi Morrison 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 yohgaki@ohgaki.net