On Mon, Jan 19, 2015 at 6:41 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi! > > > This is pretty horrible and should be fixed by making sure that > > I don't see why it's so horrible. In fact, handling null is easier than > handling exception (and faster too, probably). Many functions that try > to create objects return null or false when unable to. Of course, we > could change it by introducing exceptions to core, but I don't see why > do it peacemeal then. > > > constructors either return an object or throw an exception. > > Additionally the exception policy for core (that was previously > > discussed here: http://marc.info/?t=119263748000001&r=1&w=2 ) should > > be updated so that any constructor returning NULL is considered a bug, > > no matter what the ini settings are. To be clear, procedural code > > should behave as before, with users expected to check for errors. > > This would be a BC break for people who are handling the constructor > > returning null currently, as they would need to wrap that code with an > > try/catch block. > > That means the same failure of collator construction now needs to be > handled in two different ways. > > > Constructors give warning, but are then in an unusable state > > ------------------------------------------------------------ > > Several constructors check the parameters that they are given.....and > > then just give a warning when they are not acceptable. e.g. > > These should be fixed to either return null or throw exception, but the > behavior should be unified for everybody. > > > Again, this should be fixed by changing the constructors to throw an > > exception if the input parameters are not acceptable. > > The next question would be - if the ctors throw an exceptions, why > factory methods shouldn't? They are doing the same work essentially. > > > Constructor gives error > > ----------------------- > > > > Some constructors check the parameters they are given, and then emit > > either a 'Catchable fatal error' error or other error e.g. > > This is even bigger can of worms. If we wrote PHP today from scratch, > catchable fatal errors would be exceptions. But they are not, so we need > to deal with it - by either leaving them as is, or converting them all > together. > > > > > <?php > > $foo = new IntlGregorianCalendar(new StdClass); > > //Output: Catchable fatal error: Object of class stdClass could not be > > converted to string in.. > > This is not property of the ctor, it's property of parameter handling. > I.e. if you do it for IntlGregorianCalendar, you should do it for every > class that gets incompatible parameters. And probably user-space funcs > too since there's no reason for them to behave differently. I actually > wouldn't mind that, but this is yet bigger can of worms as it requires > refactoring a lot of assumptions on how parameters are parsed. > > > i) Can anyone see a big hurdle in fixing these behaviours, other than > > it being a BC break for people who are currently relying on these > > behaviours ? > > Yes. The first hurdle is to understand which of these behaviors need > fixing, and how, which you seem to dismiss as obvious but it's really > not. The second is to do it in consistent manner so it doesn't again > come out as part of the functions do one thing, another part another, > and third part something else different. > > > ii) Are there any other bad behaviours that people are aware of that > > ought to be fixed at a major version? > > I think we have enough for now to discuss here, so if we want do discuss > other behaviors better to open separate thread. > > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Hi, AFAIK (based on http://www.mail-archive.com/internals@lists.php.net/msg43237.html and other discussions) errors in constructors should throw exceptions (even for classes in core). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
