Re: Class constructor behaviour

On 19 January 2015 at 05:48, Stanislav Malyshev <smalyshev@gmail.com> wrote: > Hi! > > > A constructor that fails is a hard failure (factory method failed to > > produce the expected value), and is an exceptional case that can or > cannot > > be handled (via catch). > > It's not just a failed operation (expected to eventually fail), but > > something really went wrong, badly. > > Why it is different from any other failure? I.e. fopen("doesnotexist", > "r") produces false and it's not "hard failure". But if files were > objects, new File("doesnotexist", File::READONLY) suddenly becomes "hard > failure"? How the latter is harder than the former? I would say it's > exactly the same. If you say "new File" can only throw, you should also > say fopen() should only throw. If fopen can return error value, so can > File::open(), so can new File. > Excerpt from SplFileObject's manual page [1]: Throws a RuntimeException if the filename cannot be opened. [1] http://php.net/splfileobject.construct > The difference would be if File object would be built so that "new File" > should never fail, and opening would be done with "$file->open()" and > not with the ctor. But most of the object APIs in PHP are not written > this way - for these APIs, ctor failure is not something exceptional > more than failing to open file is exceptional. > > > Additionally, it makes no sense to have inconsistent behavior between > > internal classes and userland classes: it is currently impossible for a > > userland class to have the new operator producing an > > object that is not > > an instance of the class after that operator. > > That can be changed if needed. This is just a missing feature. > > -- > Stas Malyshev > smalyshev@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >