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.
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
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
