> On Oct 21, 2019, at 4:38 PM, Benjamin Morel <benjamin.mo...@gmail.com> wrote: > Sure, you can do without exceptions. I think what you're suggesting is > similar to Go's error handling.
Yes, it is like Go's error handling. > But PHP at some point decided in favour of > exceptions, so it would be logical to pursue in that direction. Must we? Maybe it is time to (at least) consider alternate approaches? Not to deprecate Exceptions — as many prefer to use them — but as an alternative to Exceptions for those who would prefer to use error values instead? > 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. Are you sure? Could a file system function not just as easily "stop" and return an error value vs. throwing an exception? > To take the mkdir() example, the only reasonable failure reason I can think > of that would not justify throwing an exception, is when the directory > already exists. > > So I would be OK with this: > > mkdir(): bool; // true if successful, false if the target directory already > exists > > This is, IMO, the only time we can safely proceed while ignoring the > outcome of the operation, as the filesystem is in the same state whether or > not the function succeeded (the directory exists). All other outcomes are, > IMO, exceptional situations, and throwing an exception is a safe way to > guarantee that execution will *not* continue after such an error. Why must it be a thrown exception vs. a returned error object? For a given application that failure might not be exceptional; the app might have a fallback solution that want to use instead. > 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. And if people don't > strictly follow the rules, you're opening the door to a whole lot potential > bugs in codebases. And, you miss the ability of automatic error reporting > for uncaught errors, that you get almost for free with exceptions and a > single try/catch at the top level. That is definitely a good argument to keep supporting Exceptions in PHP. But not an argument to make Exceptions the only approach. I have been coding professionally for a really long long and — until recently — never felt like I was happy with how I was doing error handling, always thinking I would "get around to figuring out a better approach." Then about a year ago I started using Go, and Go's approach to error handling just clicked for me. Go's philosophy is to handle the error as soon as you one is aware of it and to only ever handle it once. Since I have been using that strategy I have become very happy with my error handling, and I now (attempt) to use the same strategy in my PHP code. In PHP I now typically wrap anything that can generate an exception in my own try_catch() function, and that function returns an error object I can then process if an except is thrown inside. But it is visually ugly and tedious to have to use that function all the time. So what I am hoping for is that PHP recognizes there are two strategies for error handling — 1. Throwing exceptions vs. 2. Returning error values — and that PHP 8.0 and behind will respect programmers and allow them to embrace the strategy they feel is best for their use-case. -Mike
