On 1 March 2015 at 22:05, Stanislav Malyshev <smalys...@gmail.com> wrote:
> I'm not sure why this RFC assumes the exception is much better than > returning null. > > It is a long standing tradition in PHP that operations that can be > expected to fail - like fopen().. do not produce > fatal errors but instead return error values which can be checked for > and handled. The difference is that fopen can fail even if passed parameters that are correct e.g. due to file permission problems. Because of that the failure is not exceptional and so needs to be checked. Having to do this through exceptions would be annoying which is why people prefer to use procedural function for handling files, even when OO style interfaces are available. When a user calls `new NumberFormatter()` they can know ahead of time whether the parameters are valid or not. Any call with valid parameters will succeed. Calls with invalid parameters will fail. Because the programmer should only be passing in valid paramters any failure is by it's nature an unexpected error. And to be precise, fopen does not return error values. It returns a single error value of false. There is no indication of why the error occurred. Exceptions allow a message to be attached saying what went wrong, which is why they are preferred in a lot of cases. > But I think we can do better rather than that and have more > flexible error handling - even if it would require people to be > introduced to a concept they were not familiar with before coming to > PHP, such as not using exceptions for everything. You are one of the very few people who don't like exceptions. I completely agree exceptions shouldn't be used everywhere and that they should be used only for exception circumstances. But the vast majority of PHP programmers are completely used to them. If you don't see the benefits of using exceptions in some cases by now, it's very unlikely that any argument is going to persuade you of how they can be used (judiciously) to write clean code. Luckily, this RFC isn't a general discussion about error handling, it is specifically about the behaviour of internal classes being 'special' either by having behaviour which is not possible for userland classes to do, or just being unusable after being instantiated due to incorrect parameters. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
