Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127202
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 27 Apr 2025 13:06:53 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <ded712fb-b339-4160-8625-0f778a9c3926@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8CNTwOtsUbAbH-0Kk1Ck3DZ1fKF=P9GfctwDk9KmCr2XQ@mail.gmail.com>
References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com>
 <CAMW7n8CNTwOtsUbAbH-0Kk1Ck3DZ1fKF=P9GfctwDk9KmCr2XQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Concept: Lightweight error channels
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

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