On 02/03/15 04:10, Stanislav Malyshev wrote: >> 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.
If an object can not be created then the handle should be null. That is all that is needed. It's no different to a result being an empty string. If one is catering for the fact that there is no result then it's not an exception and we either handle the empty result or just carry on. Nothing here has any bearing on 'modular programming' it is all perfectly well handled. >> > 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). Simply follows on from above. If we need to know why there was no object created we ask ... if we have no need to know AT THIS STAGE we would have to handle the exception to get back to the normal flow? >> > 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. Exceptions are perfectly valid when the work flow has to be interrupted for something that can't be catered for in the normal flow. 'Engine' exceptions due to lack of resources and trying to execute something when the object was not created. There are certainly 'exceptions in the engine' where catch would be helpful and perhaps avoid the number of white screens I currently see, but I feel that THAT particular RFC may open the door for more general 'exception' switches? >> > 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. Seconded ... that people try to work in ways they are used to rather than in ways that are operationally more efficient is the problem. Just as many 'older' PHP users are more used to a different style of 'modularity'. It's not wrong and it may be that better education is what is missing ... both ways. >> > 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. We can agree that any process that can create a handle to an object which can't actually function as requested then it is an error that needs fixing. Some of the shortcoming of PDO may well be candidates for an exception, but that is only because they don't follow the rules used for other database extensions. Similarly a number of the other packages you have identified need similar shortcoming fixed, but FIXED rather than simply now adding an exception to hide the poor modularity of the package! The 'correct' work flow question should be "Can I correct the error in the parameters passed?" If the answer to this is yes, then the object should at least be in a stable state to allow that. If there is no object, perhaps because a file does not exist, then the work flow may already define the next step ... create the file ... then if that does not work one may bow out with a null object, or leave an object with a valid handle but with a state showing why it's an empty object. The only package I use on the list is PDO, and where that returns 'null' is totally the correct result. I can see where this is also perfectly correct for some of the other situations as well. The Reflection stuff is something I have yet to find an use for ... a decent IDE is still the right place to do most of that ... but your examples are areas where the other RFC comes into play anyway. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
