On 21/10/2019 21:38, Benjamin Morel wrote:
Sure, you can do without exceptions. I think what you're suggesting is
similar to Go's error handling. But PHP at some point decided in
favour of exceptions, so it would be logical to pursue in that direction.
I didn't say "do without exceptions", I said "use exceptions when
they're the right tool, and other tools at other times".
I would classify most, if not all, filesystem-related functions as
mostly "yes, do stop execution by default when something fails". So
this is, as well, in favour of exceptions.
You've backed that up with exactly one example function, and immediately
concede a case where you might want a non-exception flow. Here are a
handful more examples off the top of my head:
* Attempt to atomically lock and open file, returning either a file
handle or a "could not lock" status.
* Attempt to read from a file, terminate loop when the file handle
reaches EOF.
* Attempt to delete file, ignore if it doesn't exist.
All of these are candidates for returning false, or an error code, or an
object in a particular status. They could be handled with exceptions,
but that would force common patterns to use exceptions for flow control,
which is generally seen as a "bad smell".
Handling each and every error manually by using the return value
requires a lot of discipline, which could be a very steep learning
curve for PHP developers used to a fast prototyping language.
Again, I am not saying that every function should have a complex
error-handling system. It may well be sensible to have a function for
"open file, I don't expect anything to go wrong" which throws an
exception, and a separate one for "try to open file, and report the
result without ever triggering an exception". That's the point of
designing a new API, to work out what the use cases are, and cater for
them in a clean way.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
