Hi
On 4/27/25 23:47, Máté Kocsis wrote:
[…]
Thank you. I have just given the RFC another full read (the 2025/04/27
21:44 version) and I do not have any further remarks. I'm happy with
everything that is said in the RFC and I'm really looking forward to
vote “Yes” :-)
Best regards
Tim Düst
Hi Tim,
> In https://news-web.php.net/php.internals/127114 I suggest to only
> provide the "non-raw" methods, so I believe you misread that. I've just
> given the RFC another read and thought about the naming and I believe I
> still prefer not having the "raw" in the name:
>
> - Having the `raw`
Hi
On 4/27/25 23:16, Kamil Tekiela wrote:
The exception message MUST NOT be the only means of distinguishing
exceptions. Any two exceptions with different messages MUST be
identifiable either by a unique exception class name or code.
Thank you. I have used that as the basis for this change:
h
>Do you have a wording suggestion to make it clearer what is meant by
that sentence?
How about this:
The exception message MUST NOT be the only means of distinguishing
exceptions. Any two exceptions with different messages MUST be
identifiable either by a unique exception class name or code.
Hi
On 4/27/25 22:50, ignace nyamagana butera wrote:
I understand that but then I fail to see the added value of the parse
method vs the default constructor since from the RFC the only difference is
that the parse named constructor should instead of throwing return null. If
the parse method can s
On Sun, Apr 27, 2025, at 22:40, Kamil Tekiela wrote:
> >The exception message MUST NOT be the only property that allows to
> differentiate different types of error that the user may be interested in.
>
> What does this mean exactly? Can you give an example?
>
Many people don’t know about the $
Hi
On 4/27/25 22:40, Kamil Tekiela wrote:
The exception message MUST NOT be the only property that allows to
differentiate different types of error that the user may be interested in.
What does this mean exactly? Can you give an example?
This is intended to say “if a user calls ->getMessage(
Le dim. 27 avr. 2025, 22:32, Tim Düsterhus a écrit :
> Hi
>
> On 4/27/25 22:30, ignace nyamagana butera wrote:
> > $url = Uri\WhatWg\Url::parse("/foo", ".com"); //
> > Throws Uri\WhatWg\InvalidUrlException because of $baseUri
> >
> > Since parse is used shouldn't it return null in
>The exception message MUST NOT be the only property that allows to
differentiate different types of error that the user may be interested in.
What does this mean exactly? Can you give an example?
Hi
On 4/27/25 22:30, ignace nyamagana butera wrote:
$url = Uri\WhatWg\Url::parse("/foo", ".com"); //
Throws Uri\WhatWg\InvalidUrlException because of $baseUri
Since parse is used shouldn't it return null instead of throwing ?
In this case the `$baseUri` is invalid. Since this
Hi Maté
I see you updated the RFC but I believe there's still some errors in the
example:
$url = Uri\WhatWg\Url::parse("/foo", ".com"); //
Throws Uri\WhatWg\InvalidUrlException because of $baseUri
Since parse is used shouldn't it return null instead of throwing ?
$uri =
Uri\Rfc
Hi
as announced in the URI RFC discussion thread
(https://externals.io/message/123997#127142), I've now written up an
“Exception Hierarchy” policy RFC together with Gina.
Please find the following links:
RFC: https://wiki.php.net/rfc/extension_exceptions
Policy PR: https://github.com/php/pol
Thank you all for the feedback.
> I don't fundamentally disagree with the attempt to codify something
> here, but ultimately the PHP language does and will continue to profit
> from some flexibility in these regards.
@Bob, I agree that flexibility is desired. That's why I would like to have
rathe
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
On Sunday, 13 April 2025 at 22:07, Jorg Sowa wrote:
> Thank you all for the feedback on the topic of BC breaks in argument
> validation https://news-web.php.net/php.internals/126706
>
> I have collected all concerns, prepared an RFC for this change, and I'm
> opening discussion on its content:
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
24 matches
Mail list logo
