Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73653
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.169 as permitted sender)
Message-ID: <53459231.2080402@gmail.com>
Date: Wed, 09 Apr 2014 19:32:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Marco Schuster <marco+php@m-s-d.eu>
CC: PHP Internals <internals@lists.php.net>
References: <53446FC5.7000001@gmail.com> <CAMauByWD-7BfsaK+cAPdMU3LeYjzLqzpQE8hTckg_XLm22Z_-A@mail.gmail.com>
In-Reply-To: <CAMauByWD-7BfsaK+cAPdMU3LeYjzLqzpQE8hTckg_XLm22Z_-A@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------020101050209030005030308"
Subject: Re: [PHP-DEV] [PHP.next] Error-handling using "Error Events"
From: rowan.collins@gmail.com (Rowan Collins)

--------------020101050209030005030308
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Marco Schuster wrote (on 09/04/2014):
> The fopen shut-up actually could be resolved much, much more elegant:
> make it throw*real, usable exceptions*, instead of returning a FALSE
> and spitting out a warning.

Good point. Perhaps the real question is: what are the use cases - real 
or perceived - for the @ operator, and how, if we were re-organising 
error and message handling in general, can they best be replaced.

The only problem is that changing the behaviour of such a basic function 
is quite a major compatibility break, and there may need to be some way 
of switching to the old behaviour in order to use code which pre-dates 
the change, or write code which works in both versions.

> Something like DomainNotFoundException, ConnectionDeniedException,
> FileNotFoundException or whatnot. It's a nightmare if you actually
> want to know what happened.

The problem with such specific exceptions in this case is that different 
stream wrappers would want to throw completely different exceptions; I 
guess they could all extend a generic FileAccessException.

Regards,
-- 
Rowan Collins
[IMSoP]

--------------020101050209030005030308--