On 8 January 2016 at 16:51, Rowan Collins <rowan.coll...@gmail.com> wrote: > I detect sarcasm here, and would like to hear a non-sarcastic version of > your point.
You're suggesting that we solve a problem in a way that pretty much every other attempt to do has failed. I'm not going to be able to point to a single reason why attempting that solution is not going to work, as the problem comes from the result of many small problems, none of which are a complete show stopper individually. But what you're doing is saying "Why don't we solve it like this? I can't see how difficult it could be". It's a tactic that has(, even if you didn't mean to,) a tendency to shut down a particular conversation until another branch of the conversation has been pursued. I do encourage you to try to attempt to make that API - it's only by encountering all of the small problems that you can realise that although they are not perfect, exceptions allow much nicer APIs than error checking. Or alternatively you might prove me wrong! and we end up with a much better solution! > if an operation has encountered an unexpected but non-fatal condition, > it should signal that with something other than an exception (for > instance, returning a success boolean or status flag). This is a big bit of the problem. Having to remember to check for errors make the api difficult to use. If you ever forget to check for an error condition, then you have a bug in your code. And people are not perfect, so people forget stuff....which is a bad start. And it gets really annoying when there are multiple error states e.g. for mkdir the operation can fail because: * The directory already exists. * The program doesn't have permission to create the directory. * You're trying to create a sub-directory of a directory that doesn't exist and forgot to set the '$parent = true' flag. So, now the programmer needs to be able to query what type of error happened. But worse than that, what happens when there is a new error condition is added to any function? All code that was written before the new error condition was added needs to be updated to check for the new error condition. Exceptions don't have these problems. If you forget to try/catch an exception it bubble up and fatals your program, which is much better than continuing in an unknown error state. Individual error conditions can throw separate sub-types of exceptions, that indicate exactly what error condition occured, which is a very convenient way of allowing people to declare "These are the type of errors I can handle, all others I can't". If an new exception can be thrown from a function, then all existing programs continue to work as before. Again, if that new error condition is met, an exception is thrown, rather than blindly continuing in an error condition. Aka with exceptions, people writing code can say "These are the exceptions I can handle, all other error conditions are errors", whereas the logic is reversed for checking errors where it is a case of a user saying "These are the error conditions that need to fatal, all others are fine". > Can you give an example of an operation where it would be > reasonable to throw an exception, but also reasonable (and common enough > to affect the design of the API) to completely ignore that exception and > carry on? mkdir is a great example of something that has multiple error conditions. If you're trying to create a uniquely named directory, then the failure to create it is an error. If you want to just ensure a directory exists before putting a uniquely named file inside that directory, then the failure to create the directory through mkdir is not an error condition. As I said, this is not a water-tight argument against what you're suggesting. But saying it's "perfectly reasonable to implement" something in a way that every other attempt has failed....and not giving any details of how it would actually work, is not a fantastic contribution to a discussion. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
