Hi Bob, On Tue, Dec 6, 2016 at 10:36 PM, Bob Weinand <bobw...@hotmail.com> wrote: > Am 06.12.2016 um 08:06 schrieb Yasuo Ohgaki <yohg...@ohgaki.net>: > > Hi all, > > *snip* > > * Why it does not use exception for error? > > Session module uses "errors", not "exceptions" basically. Session save > handler uses "errors" also. We should avoid inconsistency in a module. > Exception adoption will be addressed and exceptions will be used > consistent manner by other RFC. > > > This is not session module specific, your interface is specifying a return > type. Thus this should be enforced on the interface implementation level. > (I.e. it will be impossible for an user to define a function not having a > return type of string/array) > > Also, if a wrong argument is passed to a function, it should throw a type > error. Perhaps old modules from pre-PHP 5 do emit warnings or recoverables, > but we then shall transition from that to TypeError, and definitely use > TypeError in new functionality.
If we use TypeError for this, session will be the first module that uses TypeError in module. It may be better to use TypeError with caution. Let's have a RFC for exception usage guideline. There isn't clear consensus how we should use exceptions now. When we have consensus, we follow the guideline. For the time being, let exception usage is out of this RFC scope Since this RFC is targeting master (7.2), we have enough time for exception adoption. P.S. I don't like mixing errors and exceptions for submodules, serialize and save handler. Please note that save handlers raise "error" for invalid return types currently. If a module should adopt exception, all applicable errors should be changed to exception at once, and patch work should be avoided. IMO. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
