On Sun, Apr 27, 2025, at 20:06, Larry Garfield wrote:
> I'm going to respond to points raised by several people together; I'm using
> Ed's message as a starting point but this is also i response to Niels, Rob,
> and Andreas.
>
> On Sun, Apr 27, 2025, at 3:16 AM, Edmond Dantes wrote:
> > Good afternoon, Larry.
> >
> > Looking at the comparison table, it seems that the two most important
> > differences are:
> >
> > 1. Backtrace consumes a lot of resources.
>
> Yes. And even if it can be made faster (as it looks like Niels is doing,
> which is great), it will never be as fast as an empty constructor and a
> return. That's the level I'm proposing.
>
> > 2. There is an explicit contract for exceptions thrown by a function.
>
> Yes.
>
> > 3. I didn't fully understand the point about the exception hierarchy,
> > but it seems important too.
>
> I somewhat glossed over this point, but let me expand on it here.
>
> Exceptions currently have a Java-inspired hierarchy. Everything MUST extend
> either Error or Exception. The available exceptions are spread across core
> and SPL, but internals is not supposed to use the SPL ones.
>
> For the use cases I'm talking about, "InvalidArgumentException" is the most
> common case, I expect. Or rather, special cases of that. However, it
> extends LogicException, which is specified in the docs as "Exception that
> represents error in the program logic." Which is... *wrong*, because half
> the time or more an InvalidArgumentException is a case of validating user
> data that cannot be fully validated by the type system... and thus not really
> a programmer error. It's only a programmer error if they don't handle it
> gracefully.
>
> Moreover, all exceptions currently track:
>
> * message
> * code
> * file
> * line
> * trace
> * previous exception
>
> Those are useful when they show up in logs read by a human. For the use
> cases I am describing, none of them are relevant, useful, or desireable.
> These values are for programmatic use only. But all of those are baked into
> the exception system at its core. Just having a third "kind" of exception
> (in addition to `extends Error` and `extends Exception`) would not really
> solve anything.
>
> > The issue with the missing contract could have been solved even for
> > exceptions, without creating a new entity.
>
> This is incorrect, as making the current exception system checked would be a
> ginormous BC break. And having some throwables be checked and some not, but
> using the same syntax and class hierarchy... well, that's the reason everyone
> detests Java's exceptions. Let's not do that.
>
> > Regarding Backtrace, the following questions seem fair:
> >
> > 1. What if I want to know where the situation occurred? Can I just
> > ignore this information?
>
> That is completely and utterly irrelevant, just as it is completely and
> utterly irrelevant on which line a `return` statement appeared.
>
> I think the framing of this concept as "lighter exceptions" is the wrong
> lens. I probably contributed to that in my initial explanation, so let me
> try and clarify:
>
> What I am proposing is not "Better exceptions." It's "a second kind of
> return value." It's closer to Rust's Result types or Go's multi-returns, but
> spelled differently. That is, it turns out (see the Error Model article
> previously), logically identical to checked exceptions. But if the mental
> model of "what is an exception" is what PHP has today, then that is more
> misleading than helpful. So let's not talk of that further.
>
> Rather, consider this example:
>
> class Repo {
> public function getUser(int $id): User {
> $record = $this->db->query("...")->fetchOne();
> if ($record) {
> return new User(...$record);
> }
> // Uh, now what?
> }
> }
>
> There's various ways to handle that case. Sticking an exception at the end
> of the method is one option, but as I've pointed out, a particularly bad one.
> "That user isn't here" is not an error case that should be able to silently
> crash the application, just because someone put an invalid number in a URL.
>
> We could make the return value ?User and then return null, but now we have to
> manually check for null every frickin' time we call the method, or we get
> random null errors in who knows where. And it doesn't let us differentiate
> between "user not found" and "that is a negative int, which is never correct
> you idiot."
>
> Suppose a hypothetical world where we had generics:
>
> // We literally need *nothing* on these classes other than their type.
> // More complex cases might, but in this case, anything more than this is a
> waste.
> interface RepoErr {}
> class NoSuchUser implements RepoErr {}
> class NegativeId implements RepoErr {}
>
> class Repo {
> public function getUser(int $id): Result<User, RepoErr> {
> if ($id <= 0) {
> return new Result::err(new NegativeId());
> }
> $record = $this->db->query("...")->fetchOne();
> if ($record) {
> return new Result::ok(new User(...$record));
> }
> return new Result::err(new NoSuchUser());
> }
> }
>
> And then to use it, you MUST do:
>
> function doStuff($id) {
> $ret = $repo->getUser($id);
> if ($user instanceof OK) {
> $user = $ret->value;
> } else {
> if ($ret->err instanceof NoSuchUser) {
> display_user_message('Who is that?');
> return;
> } else if ($ret->err instanceof NegativeId) {
> display_user_message('Buddy, that's not a thing.");
> return;
> }
> }
> // If you got here, it means the getUser call way way way up there was valid.
> }
>
> I think it's reasonably obvious that is extremely clumsy, which is why almost
> no one in PHP does it, including FP stans like me. Plus that whole generics
> thing.
>
> What I've started doing is using union returns as a sort of "naked result":
>
> class Repo {
> public function getUser(int $id): User|UserErr {
> if ($id <= 0) {
> return new new NegativeId();
> }
> $record = $this->db->query("...")->fetchOne();
> if ($record) {
> return new User(...$record);
> }
> return new NoSuchUser();
> }
> }
>
> function doStuff($id) {
> $user = $repo->getUser($id);
> if ($user instanceof UserErr) {
> ...
> }
> $user is now usable.
> }
>
> But that relies on me always remembering to do that check, and means static
> analysis tools can't know what the type of $user is until I check it.
> Better, still not great.
>
> What I am proposing is to take the Result type example and change the
> spelling to:
>
> class Repo {
> // We get reliable type information without generics!
> public function getUser(int $id): User raises UserErr {
> if ($id <= 0) {
> raise new NegativeId();
> }
> $record = $this->db->query("...")->fetchOne();
> if ($record) {
> return new User(...$record);
> }
> raise new NoSuchUser();
> }
> }
>
> And then something reasonable on the receiving side, which I've not fully
> thought through yet. The whole point of this thread is "should I take the
> time to think that through?" :-)
>
> If we used try-catch or something structured the same, then we at least get:
>
> function doStuff($id) {
> try {
> $user = $repo->getUser($id);
> // Code that uses $user, which is guaranteed to be a User.
> return ...;
> } catch (NoSuchUser) { // Note not capturing the value, as we don't need
> it in this case.
> display_user_message('Who is that?');
> } catch (NegativeId) {
> display_user_message('Buddy, that's not a thing.");
> }
> }
>
> I'm not convinced that's the right syntax, but it's a possible syntax. If
> you want to defer handling of a particular error to the caller, then you
> would explicitly do this:
>
> function doStuff($id): string raises UserErr {
> try {
> $user = $repo->getUser($id);
> // Code that uses $user, which is guaranteed to be a User.
> return ...;
> } catch (UserErr $e) {
> raise $e;
> }
>
> Which is why I think we do want some kind of syntax similar to Rust's ?, so
> the above could be shortened back to this:
>
> function doStuff($id): string raises UserErr {
> $user = $repo->getUser($id) reraise;
> // We have a good user.
> }
>
> If you try to raise an error from a function that doesn't specify it... that
> is exactly the same as trying to return an array from that function. `return
> array` would be a type error on the success channel. `raise new ProductErr`
> would be a type error on the failure channel. Same idea.
>
> Again, I don't think try-catch in its current form is ideal. I'm not sure
> what is. I'm trying to decide if it would be a waste of my time to figure
> out what would be better. But again, this is *not an exception*. This is a
> second return channel, aka a different way to spell a Result type, such that
> we don't need a clumsy Result type.
>
> --Larry Garfield
>
Hmmm,
Reminds me of working on wordpress's backend, where you would write something
like
function get_user(): WP_User|WP_Error
-- or something like that (it's been a long time).
But if it was an exceptional error, you'd just throw. But, you'd have to write
something like this every time you called it:
if (($user = get_user()) instanceof WP_Error) { /* handle error */ }
// $user is WP_User
What you're suggesting is basically providing this via a separate "track" or
"channel" so it would look like:
function get_user(): WP_User raises WP_Error {}
$user = get_user() reraise;
I understand that these are mostly lightweight, programatical errors, not
exceptions. So, for example, running out of disk space, "not found" results,
etc. These are things you should just handle ... not report. However, there are
cases where these do become exceptional further up the stack. For example, if
you are supposed to be storing a profile image and you cannot recover from a
full disk or a user that the client thinks exists -- you probably want to turn
them into an exception. Maybe something like this:
$user = get_user() reraise (WP_Error as LogicException);
where you can specify an error to be wrapped in an exception. The stack trace
and everything would come from this line, not where the error actually came
from. That shouldn't be an issue though, in most code.
— Rob
