> De : Dan Ackroyd [mailto:dan...@basereality.com] > > This is pretty horrible and should be fixed by making sure that > 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.
I would prefer deciding that returning null is the standard way for a constructor to inform the PHP core that the object creation failed (for any reason). This would be trapped by the core and cause a catchable fatal error. This is more compatible with the 'exception-less' behavior of the core in general. The constructor is still free to throw an exception but this wouldn't be encouraged nor the standard way to inform the core that an error occurred. It also allows for minimal code changes. This could be split in two steps. First, the core is modified to trap null return values from constructors. Then, class constructors who did implement another mechanism can be modified one by one. I think that it is also better for PECL extensions as, if we don't introduce the check in the core, it is just a convention that extension developers *should* follow. BC break would be minimal too (would only impact for few programs who had ways to manage null return values from constructors). > Constructors give warning, but are then in an unusable state > ----------------------- Same, should return null and not create object. > Constructor gives error > ----------------------- Should return null, and the core would raise the error. No BC break here (except loosing a possible explanation in error message, but is it a BC break ?) > These changes would need an RFC to be approved I presume. However > doing the RFC would probably require making a patch that implements > most, if not all, of these changes. IMO, you should write the RFC, as it would be quite fast (even if you forget to list some classes). Please mention at least your option and mine. On such a subject, I wouldn't implement anything before approval, even a non-official one. We don't need a POC here, as everybody clearly sees the impact the change would have. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
