Hi! > 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
Failure of the formatter on wrong format or data is of the same kind - its not exceptional and only caused by input data that could be right but in this circumstance aren't. > When a user calls `new NumberFormatter()` they can know ahead of time > whether the parameters are valid or not. Any call with valid I certainly don't see how this can be true. The code can receive generated format and user-supplied locale (e.g. loaded from resource files and HTTP headers) and the developer can have no idea if it's correct or not. Exactly the same as with files or date_create(). > Because the programmer should only be passing in valid paramters any > failure is by it's nature an unexpected error. That's exactly like saying programmer should only try to open existing files so any failure by its nature is an unexpected error. You are trying to create a difference when there's none. But if you don't like fopen() there are many other factory functions that behave the same - like date_create() or simplexml_load_string(). You can claim that all these failures are somehow "not exceptional" and only date formatting using NumberFormatter is somehow "exceptional" but that doesn't sound very logical to me. > 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. This is not relevant since error information can be retrieved by other methods, and intl has such facility (as do other APIs, most of the APIs have facilities to retrieve error information and very rarely they rely on exceptions for that - exceptions are not very good means of doing that). > You are one of the very few people who don't like exceptions. I Who said I don't like exceptions? I like exceptions, I adore, cherish and admire them - when they are used appropriately. What I am saying is not that exceptions are universally bad - but they are also not universally good, they should be used sparingly, in appropriate places, and not every situation where something is not going as planned should necessarily be an exception. > should be used only for exception circumstances. But the vast majority > of PHP programmers are completely used to them. They can not be used to them in the context of this RFC since PHP never had them in such context. They can be used to them in different contexts, but I've also seen a lot of boilerplate code and unclear error reporting growing from the fact that some code is too exception-happy. > 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. If something is unusable after being instantiated, it would better just let the user handle it instead of producing bad object. I agree with that - if you produce an object, it should be useful, otherwise no point in it. However, I disagree with the other part. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
