Concept: Lightweight error channels

There's two key problems with exceptions as PHP currently has them:

1. Creating and attaching the backtrace to them is stupidly expensive.
   It's one of the most expensive things you can ask the engine to do, I
   think.

Would an EmptyBacktraceException solve it then? Ideally a LightException
would gather the call stack in it's backtrace as it bubbles up until
it's caught. It migth solve most of the legit reporting needs with an
insignificant performance impact. No idea if it's doable though.

2. They're unchecked, which means as a developer calling a function you
   have absolutely no idea what exceptions it might throw without reading
   every line of that function and every function it calls, transitively.
   That means it's extremely easy for an exception to kill the process if
   no
   one expects to catch it.

Why wouldn't these raises end up with the same issue? I call
inverse($x) of a lib, it calls div(1, $x) internally, fails to
handle the raise and I end up with a crash/exception of the old kind.

Or is inverse forced to check every possible raise of div? But
that's probably clumsy, sometimes redundant and not something that can
be enforced during compilation. So we still end up with runtime
exceptions from somewhere deep in the lib, but instead of "ZeroDivisor"
they are "unhandled raise" exceptions?

Sorry, I guess this somewhat overlaps with the bubbling portion that you
haven't thought through, but I'm continuing to ask because it seems I'm
not the only one having hard time to grasp the feeling of the proposed
model.

BR,
Juris

Good afternoon, Larry.

Looking at the comparison table, it seems that the two most important differences are:

Backtrace consumes a lot of resources.

There is an explicit contract for exceptions thrown by a function.

I didn't fully understand the point about the exception hierarchy, but it seems important too.

It seems to me that the Backtrace issue is a problem of a low level of abstraction — the implementation of exceptions. That's one problem. The lack of an explicit contract is a problem on a completely different level of abstraction.

The issue with the missing contract could have been solved even for exceptions, without creating a new entity.

Regarding Backtrace, the following questions seem fair:

What if I want to know where the situation occurred? Can I just ignore this information?

For the type of failure we are talking about, there is not really the
need for a backtrace.

If yes, why not create an option to disable backtrace generation for exceptions?

Regarding the Result/Error type.

I have experience using this approach in remote services, where exceptions seem inappropriate.
It’s probably possible to use it even now without generics, and without any special language features.

What if we focus on:

Improving exception handling, making it as lightweight as in Python.

Introducing explicit exception contracts.

Best Regards, Ed.

I'm not going to lie, I spent nearly an hour last night attempting to create an exception without a stack trace. I was quite surprised at how impossible it is. The engine really goes out of its way to ensure the trace is set.

One thing you can do is throw the same exception again.
Not really a good solution though.

A simple solution (for this problem) may be creating a new exception type \LightException or something that would allow for never setting a stack trace. This is pretty heavily on the "pragmatic" side of the solution space, but it is also relatively simple.

The main obstacle here is interface Throwable which promises to have a
file, line number and backtrace.
Currently you can only throw objects that implement Throwable.
https://3v4l.org/LHhNm

If we introduce a "LightException", it cannot really extend Exception,
because then it gets all the baggage.

The solution could be a new interface "Catchable" or "Raisable". But
this would be superfluous.
Instead, we could allow to throw any objects, or introduce a new
keyword "raise", that would allow any objects.

On the implementing side, a "raise new NotFound(..)" seems mostly the
same as "throw new NotFound(..)".
On the declaration side, we might want to add " ... throws NotFound"
or "... raises NotFound", to make this part of the contract. So this
would be very similar to checked exceptions as I know them from Java.

On the calling (and handling) side, any alternative we find to "try
... catch (...) ..." might also be useful for regular exceptions.
In fact this would be the big difference to current exceptions and
return values in terms of developer experience, whereas the "no stack
trace overhead" is more an internal thing.

--- Andreas

— Rob

Hello, Rob.

I was quite surprised at how impossible it is.

static zend_object *zend_default_exception_new(zend_class_entry
*class_type) /* {{{ */
{
....
if (EG(current_execute_data)) {
     zend_fetch_debug_backtrace(

It's not that this is 100% impossible. PHP is a language with an execution
context, which means PHP can hypothetically change behavior depending on
the context. This means it's entirely possible to imagine code like:

if (EG(without_trace)) {}

One could follow Python's approach and create the backtrace only when the
exception is thrown. But this isn't a particularly elegant solution.
Besides, in 90% of cases, an exception is created to be thrown.

Use a deferred Backtrace generation algorithm? Such an algorithm is almost
impossible, because the backtrace is built based on the execution context,
which will be changed once the function returns control.

There are only two realistic options:

Either don't use a backtrace at all, or use a minimal version (only FILE

• LINE).

Generate the backtrace only when the programmer explicitly requests it,
but then accept that some information will be missing.

For example:

raise $exception — does not generate a backtrace.

throw $exception — generates a backtrace, but only from the point where
the exception is thrown.

A lightweight backtrace might be imperfect in accurately indicating the
call path if multiple functions are on the same line, but otherwise it
saves a lot of memory and CPU.

The raise/throw option might also make sense. But it has more nuances and
contradictions.

The HHVM project suggests an interesting Lazy backtrace generation
mechanism based on stack unwinding.

An exception is generated.
2.

The stack enters an unwinding mode. In this mode, PHP gradually collects
information into the backtrace.
3.

Each frame exit contributes a part of the backtrace.
4.

Once the exception is caught, the unwinding process stops.
5.

Now a decision can be made: either generate the full backtrace or

suppress the exception.

Advantages:

Allows deferring backtrace generation until the exception is caught.
2.

Allows suppressing exceptions without a backtrace, making their creation
cost cheap.
3.

Allows preserving exceptions with a backtrace only when necessary.

Disadvantages: requires added complexity.

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.

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

Hello all.

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.

If the backtrace is generated only when needed, rather than at the moment
the exception is created, there will be no difference or almost no
difference (if a stack unwinding algorithm is used).

The total number of CPU/memory operations will be approximately the same.
The only difference is that deferred backtrace generation will require more
complex frame return code, which may introduce pitfalls.
However, if a backtrace is needed by itself, such overhead is unavoidable
regardless of whether exceptions are used or not.

I somewhat glossed over this point, but let me expand on it here.

So the exception hierarchy in PHP is far from ideal. Understood. The
hierarchy can be improved to make it more logical and consistent. And as I
understand it, changing the exceptions themselves is not required for
that.

Moreover, all exceptions currently track:

Yes. And the main problem among them is the trace property. Neither file
nor line cause significant overhead, because file is a reference to a
string constant, and line is an integer.

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.

While introducing a new entity, such as a "New Error Stream" with defined
contract rules, is theoretically possible,
it would not fundamentally change the current situation.

In practice, this approach would introduce a second category of exceptions,
requiring developers to manage:

the primary execution flow,

the standard exception flow,

a "special exception flow" that must be converted back into the standard
one when necessary.

This added complexity may outweigh the potential benefits, especially given
that the primary value would be limited to preserving backward
compatibility.

It is worth carefully considering whether such a change justifies the
additional mental and technical overhead.

On the other side of the scale:

replacing @throws with a special syntax (or perhaps simply introducing a
new attribute?),

defining the behavior in case of contract violation while preserving
backward compatibility.

For example, if an exception contract is violated, an error would not be
thrown; instead, a warning would be issued, which would not break the
program's execution flow but would help draw the developer’s attention to
the issue.

Later in the letter you explain in more detail that this is not a special
kind of exception, nor a new execution flow, but rather a* special type of
result*.

But if this is a special type of result, then it should follow the same
rules as all PHP types. In other words, this cannot be solved without
generics.

However, the benefit of the new syntax, which could make the code cleaner,
does not depend on generics:
For example:

$res = someFunction() catch ($err) {throw $err;} // Like Zig?

But then the return type must be Throwable.

The advantage of generics like Result<> is that they do not create a
separate return channel.
Everything operates within a single flow.
However, this approach is not yet possible in PHP.

Introducing an additional return channel would mean increasing the overall
complexity.

Of course, this is a clean and useful syntax for such cases.
Moreover, the catch block could be made mandatory if the function is marked
with a contract — meaning the function cannot be called without a catch
block at all.

However, it seems to me that we can achieve the same result using throw,
simply by adding new syntax and capabilities. Yes, there may be some
backward compatibility issues, but is it really something to be afraid of?

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.
}

One thing about Rust's ?, compared with an additional "reraise" keyword
thingy, is that the former is inline with the rest of the expression
while the latter forces a distinct statement for each possible failure
point. The "happy path" no longer looks quite so happy.

In other words, Rust's approach looks syntactically a lot more like
PHP's "?->" nullsafe access, which can be looked on as addressing the
specific case of "returning null to indicate failure" approach to error
handling (in the even more specific case where the happy path would have
returned an object).

Regarding performance however, rather than introducing yet another completely new concept to do almost the same thing, why not try to improve exception performance instead?

I just opened a PR that makes instantiating exceptions much much faster, and this is only after like 15 mins of work. I'm sure there's even more to gain.

I mean, squeeze out gains where you can where the effort:reward ratio is good, but the following is a naive but representative result on an MacBook M3 Pro:

return false    100000 times = 0.075289011001587
throw exception 100000 times = 0.11530804634094

Do we consider a difference of 0.075/100000s vs 0.115/100000s that big a deal when compared to (e.g.) establishing a database connection?

The first part, the 0.075 vs 0.115... yeah, we care. That's 50%
slower. But the thing is, the math with exceptions is kind of knowable
because one of the key aspects of its cost is walking the call stack.
How deep is the call stack going to be when a given library throws an
exception? You don't really know.

I work for an observability company on a profiler, so I regularly see
customer call stacks. It is incredibly common to see much deeper call
stacks, especially any framework with a middleware concept. I can't
share a lot more detail without customer permission, but we do have a
blog post about a real-world situation for one of our customers which
had 85-ish frames deep when they were throwing exceptions:
https://www.datadoghq.com/blog/php-exception-profiling/.

tl;dr For this customer, throwing exceptions accounted for about 23%
of the total CPU time.

So yeah, we do care about the performance of exceptions. Granted,
code for this customer was bit of an unusual situation, but it still
matters even today. It definitely matters if people are going to start
throwing exceptions more frequently for less-exceptional errors.