> Now, there are some schools of programming that lean heavily into try/catches. Me, I find them mentally taxing. Whenever there is a try/catch, we now have to worry not only about what the function returns, but what it throws. We not only have branching logic, which increases complexity but also have to worry about dealing with two different paradigms. A function may return a value, or it may throw. Throwing bubbles if it is not caught. Returns do not. So both have to be dealt with for every function. It’s exhausting.
I tend to agree with this sentiment. I wonder whether it would have been helpful, perhaps in an alternate universe, for all functions to return a structure containing two things: the actual intended return value, and an error object (perhaps NULL if no error, to reduce overhead).
So something like `return $foo;` would imply no error but `return NULL, Error('bar')` would imply an error. Then, we could use `return` at any point to indicate success or an error depending on the case.
The only thing remaining to mimic the behavior of `try...catch` would be to make closures which could be `return`ed from, similar in concept to `throw` in that they would exit the block except that because it's a `return` it would work like any other `return` to exit the block.
Am I crazy, or would this (at least in theory) simplify the return/try/catch issues the author is talking about?
I tend to agree with this sentiment. I wonder whether it would have been helpful, perhaps in an alternate universe, for all functions to return a structure containing two things: the actual intended return value, and an error object (perhaps NULL if no error, to reduce overhead).
So something like `return $foo;` would imply no error but `return NULL, Error('bar')` would imply an error. Then, we could use `return` at any point to indicate success or an error depending on the case.
The only thing remaining to mimic the behavior of `try...catch` would be to make closures which could be `return`ed from, similar in concept to `throw` in that they would exit the block except that because it's a `return` it would work like any other `return` to exit the block.
Am I crazy, or would this (at least in theory) simplify the return/try/catch issues the author is talking about?