Hello.
> Suppressing? You mean fataling. Suppressing implies ignore, which is the
> exact opposite of what I am proposing.
Yes, it seems I didn’t explain my thought clearly.
We have the following code:
```php
function some(): bool
{
return false;
}
function target(): void
{
if(some()
Hi all,
> On May 1, 2025, at 09:29, Levi Morrison wrote:
>
> On Tue, Apr 29, 2025 at 9:48 AM Paul M. Jones wrote:
>>
>>
>>
>>> On Apr 27, 2025, at 07:26, Niels Dossche wrote:
>>>
>>> Regarding performance however, rather than introducing yet another
>>> completely new concept to do almost
> > Do we consider a difference of 0.075/10s vs 0.115/10s 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 o
On Tue, Apr 29, 2025 at 9:48 AM Paul M. Jones wrote:
>
>
>
> > On Apr 27, 2025, at 07:26, Niels Dossche wrote:
> >
> > Regarding performance however, rather than introducing yet another
> > completely new concept to do almost the same thing, why not try to improve
> > exception performance inst
On Thu, May 1, 2025, at 7:47 AM, Juris Evertovskis wrote:
> On 2025-04-29 17:29, Matthew Weier O'Phinney wrote:
>
>>
>> * Exceptions should not be used for normal application logic flow. If the
>> "error" is recoverable and/or expected, use a different mechanism so you can
>> use standard condi
On Wed, Apr 30, 2025, at 9:18 PM, Morgan wrote:
> On 2025-04-28 06:06, Larry Garfield wrote:
>> 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->getUs
On 2025-04-29 17:29, Matthew Weier O'Phinney wrote:
* Exceptions should not be used for normal application logic flow. If
the "error" is recoverable and/or expected, use a different mechanism
so you can use standard conditional branching.
As such, there are a lot of situations where I may not
On 2025-04-28 06:06, Larry Garfield wrote:
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
> On Apr 27, 2025, at 07:26, Niels Dossche wrote:
>
> 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 m
On Tue, Apr 29, 2025 at 9:09 AM Hammed Ajao wrote:
> On Mon, Apr 28, 2025, 1:22 p.m. Larry Garfield
> wrote:
>
>> On Mon, Apr 28, 2025, at 11:28 AM, Edmond Dantes wrote:
>> >> I have already demonstrated how it can be solved without generics.
>> Multiple response channels from a function alread
On Mon, Apr 28, 2025, 1:22 p.m. Larry Garfield
wrote:
> On Mon, Apr 28, 2025, at 11:28 AM, Edmond Dantes wrote:
> >> I have already demonstrated how it can be solved without generics.
> Multiple response channels from a function already exist: Normal returns
> and exceptions. Exceptions as curr
On Mon, Apr 28, 2025, at 11:28 AM, Edmond Dantes wrote:
>> I have already demonstrated how it can be solved without generics.
>> Multiple response channels from a function already exist: Normal returns and
>> exceptions. Exceptions as currently designed are just very poorly suited to
>> the p
> I have already demonstrated how it can be solved without generics.
Multiple response channels from a function already exist: Normal returns
and exceptions. Exceptions as currently designed are just very poorly
suited to the problem space I am describing.
If another error channel is introduced,
On Mon, Apr 28, 2025, at 6:46 AM, Edmond Dantes wrote:
> 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
>
> > 3) Implement a new LightException (or similar name) with no args in
> getTrace().
>
> + or 4) Deferred backtrace mechanism:
>
> 1. Does not compute the backtrace when the exception is created.
> 2. The backtrace is fully computed only if the exception is caught using a
> catch block or by a
> 3) Implement a new LightException (or similar name) with no args in
getTrace().
+ or 4) Deferred backtrace mechanism:
1. Does not compute the backtrace when the exception is created.
2. The backtrace is fully computed only if the exception is caught using a
catch block or by a global handler w
> Edmond Dantes hat am 28.04.2025 13:46 CEST geschrieben:
>
>
> 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 th
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 create
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 a
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 HHVM project suggests an interesting Lazy backtrace generation
mechanism based on stack unwinding.
1.
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
Hello, Rob.
> I was quite surprised at how *impossible* it is.
```c
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
On 2025-04-27 08:42, Larry Garfield wrote:
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 so
On Sun, 27 Apr 2025 at 14:24, Niels Dossche wrote:
> On 26/04/2025 09:17, Larry Garfield wrote:
>
> > * Exceptions are very expensive, the hierarchy is confusing, and
> handling them properly is a major pain. Failing to handle them properly is
> very easy since you have no way of knowing what ex
On 26/04/2025 09:17, Larry Garfield wrote:
> * Exceptions are very expensive, the hierarchy is confusing, and handling
> them properly is a major pain. Failing to handle them properly is very easy
> since you have no way of knowing what exceptions the code you're calling
> might throw, or its
On Sun, 27 Apr 2025 at 10:27, Rob Landers wrote:
>
> On Sun, Apr 27, 2025, at 10:16, Edmond Dantes wrote:
>
> 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 con
On Sun, Apr 27, 2025, at 10:16, 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.
>
> 2. There is an explicit contract for exceptions thrown by a function.
>
Good afternoon, Larry.
Looking at the comparison table, it seems that the two most important
differences are:
1.
Backtrace consumes a lot of resources.
2.
There is an explicit contract for exceptions thrown by a function.
3.
I didn't fully understand the point about the excep
On Sat, Apr 26, 2025, at 11:19 AM, Rob Landers wrote:
> Hey Larry,
>
> I’m still digesting this, but I wonder if this problem (errors vs
> non-world-ending errors vs happy path) is a problem due to people often
> making warnings into exceptions?
>
> I feel like many devs/frameworks “abuse” (for
On Sat, Apr 26, 2025, at 3:59 PM, Juris Evertovskis wrote:
> Hi,
>
> Reading this as a PHP dev is confusing (terminology-wise) because errors
> used to be the fatal ("stop the world") conditions while exceptions were the
> catchable, recovarable issues within some call - feels to me pretty
> equiva
> What's the problem with PHP exceptions? I'm not even trying to argue, I'm
> trying to understand. Is it the implementation (bad/expensive performance)?
> Semantics? Handling syntax?
Larry provided several problems in the opening of his email; you may
want to reread that.
I will affirm that exce
Hi,
Reading this as a PHP dev is confusing (terminology-wise) because errors
used to be the fatal ("stop the world") conditions while exceptions were the
catchable, recovarable issues within some call - feels to me pretty
equivalent to what you're proposing here.
What's the problem with PHP excep
On Sat, Apr 26, 2025, at 09:17, Larry Garfield wrote:
> Hi folks. In several recent RFCs and related discussion, the question of
> error handling has come up. Specifically, the problem is:
>
> * "return null" conflicts with "but sometimes null is a real value" (the
> validity of that positio
Hi folks. In several recent RFCs and related discussion, the question of error
handling has come up. Specifically, the problem is:
* "return null" conflicts with "but sometimes null is a real value" (the
validity of that position is debatable, but common), and provides no useful
information a
34 matches
Mail list logo
