[RFC] Extend error control operator to suppress exceptions

On 04/03/2021 14:08, G. P. B. wrote:

usage of the traditional I/O functions remains the de facto standard within the community. I don't think that this is really an argument for anything. The SPL options aren't obvious - I would wager that many, most even, PHP developers barely even know SPL exists. The SPL options aren't pushed anywhere in the manual that I'm aware of (for example, the manual page for dir() doesn't even mention FilesystemIterator / DirecrtoryIterator in any way). Many developers are already using Safe and similar libraries to get "standard library but with exceptions". If this was available in core and at least prominently mentioned, if not recommended in the manual (could we have a "note box" that's not quite a deprecation notice, but a "we strongly urge you to consider this method" in a similar fashion, if we don't already?) If the manual did a similarly better job of recommending SPL ways of doing things, I'm sure they'd get used more too. Would it make sense in some areas such as file operations to have more "topic oriented" documentation than the current pure function / class listing methodology the manual currently uses? (This might make it easier to point out alternatives or make recommendations) On a related note I dislike "documentation burden" as an argument against improvements. I obviously understand "open source, volunteers, translations, etc" but I've heard this a few times now as an argument against fixing various issues (another example is that many functions in the manual document that they can return false, but there's absolutely no explanation as to when this can occur except a single paragraph that lives on its own page that nobody is ever likely to find if they don't already know it exists and you can't tell which functions it actually applies to even if you do). Obviously the project doesn't, but if you followed this for everything (to the extreme), you'd never introduce any new functionality because it would mean adding more documentation pages. If this is an issue, does the project need to consider if there are better ways to handle documentation? Are there things the project could implement to improve documentation contributions and recruit more translators (something along the lines of "bug days" or "Season of Docs"; this might be easier to implement now that the docs are in Git(Hub)) With regards to the suggested implementations, I would prefer the improved library with exceptions option. I wouldn't like to see yet another method of error handling introduced to the standard library (such as the Go 2 returns method) - it already has too many. Things have been moving in a good direction recently with everything moving toward Throwables. I think reversing that trend is a mistake. Potentially crazy thought: Running with the "improved standard library" idea, could this be made easier for developers to use by implementing a "use fallback namespace" statement. While PHP currently falls back to root / namespace, if the new standard library were - purely for example, I'm sure others can come up with a better name - under the namespace "/PHP/standard/", developers could add "use fallback namespace /PHP/standard/;" to the top of their scripts along with the other use statements, and PHP would then try that namespace before falling back further to / when encountering undefined classes.

On 04/03/2021 14:08, G. P. B. wrote:

Hi George, This is a really creative approach to this thorny problem, and I think I like it, although I'm still working through the implications in my head. One thing I'd like to call out is that this could be useful in its own right, outside of migration strategies. One of the big downsides of exceptions is that they always cause control to jump somewhere else, even when you'd rather they didn't. Joe Duffy in an interesting blog post [1] about error handling strategies refers to it as "control-flow rather than dataflow". For instance, if you start with this: $foo = doSomething() + $bar; If doSomething() throws an exception, and you want to default to just $bar, you have to write this: try {    $foo = doSomething() + $bar; } catch ( SomeException $e ) {    $foo = $bar; } What you really want is to catch the exception, but not break the flow. With this proposal you could: $foo = ( @<SomeException>doSomething() ?? 0 ) + $offset; Which leads me to suggest changing this:

To this:

errors (E_WARNING, E_NOTICE, etc).  So @<\Throwable>expression will suppress all possible Exceptions, it does not have the same behaviour as @expression. This makes the operator useful even in situations where you want normal error handling behaviour (e.g. logging) for Warnings and Notices, but want to force an exception back into "dataflow style". [1] http://joeduffyblog.com/2016/02/07/the-error-model/ Regards,

Reading it several times, it is still not clear to me what the following means from the Proposal section: ------------------------- Add the following syntax @<union_class_list> to suppress only the exceptions within the class list, this is similar to: try { expression } catch (union_class_list) {} As such @<\Throwable>expression and @expression are identical. ------------------------- Specifically: 1. What @<union_class_list> means and what it would look like in practice, 2. What catch(union_class_list) would look like in practice, 3. What @<\Throwable>expression means and what it would look like in practice, and 4. Can you provide a few concrete code examples, please?

I am not clear what you mean by "providing a path to migrate in a BC manner" here. Would this require developers to prefix all functions calls with @ for functions changed in a future version of PHP to throw exceptions instead of returning values, assuming they do not have the green light from their stakeholders to make more substantive changes to their code? IOW, are you proposing a requirement to change existing code but in a form that could be (almost?) completely automated? Is that the how you are envisioning this aspect of BC to work?

Would you also consider adding a reciprocal `error_on_exception` declare?

What do you see as the downside of shoving more functionality into @? Is the concern anything more than making the source for PHP more complicated to maintain?

-Mike

On Thu, Mar 4, 2021, at 8:08 AM, G. P. B. wrote:

My first thought is that if you're throwing away exceptions, you're therefore performing an expensive operation (generating a backtrace for the exception) that will then be discarded, and thus is wasted effort. If people start using this frequently as a short-hand that allows exceptions as a bail-out flow contrl (whether that's good or bad, overall), that means you could end up with unexpectedly slow code that generates lots of expensive exceptions for no purpose. My first thought would be to ask if it's possible to set some contextual flag when @<Foo> is used, such that code executed in that scope will not generate a backtrace and instead throw some kind of thin exception that has only the cheap bits in it, making it less expensive. Of course, I realize that may also end up encouraging people to use exceptions for flow control, which is not ideal. Basically, my concern is that making this too easy to do: $val = @<\Throwable> something() ?? 0; will hide some nasty and hard to resolve performance bugs if something() ends up throwing a lot as a matter of course. --Larry Garfield