On 19 January 2015 at 05:48, Stanislav Malyshev <smalys...@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
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
