Hi
On 4/29/25 00:36, Larry Garfield wrote:
It's a common recommendation in userland, as it allows implementers to extend
an existing exception (eg, InvalidArgumentException) of their choice while
still being tagged as coming from a given library. Though I suppose if the
policy doc also says
On Mon, Apr 28, 2025, at 4:27 PM, Tim Düsterhus wrote:
> Hi
>
> On 4/28/25 23:09, Larry Garfield wrote:
* Would allowing an extension-tagging interface instead of a base class be
an option? It still allows for catching "anything thrown by this
extension", which I presume is the go
Hi Maté,
> I fiddled a little bit with the implementation, and I went with the
Uri\UriComparisonMode enum name at last. I hope that it is OK on your side.
If no one objects with your name choice I am fine with it, as long as it is
not a boolean :) I will adapt my polyfill. I think I have no more
Hi
On 4/28/25 23:09, Larry Garfield wrote:
* Would allowing an extension-tagging interface instead of a base class be an option? It
still allows for catching "anything thrown by this extension", which I presume
is the goal. If not, why?
See the “Choice of Base Exception” section in
https:/
Hi Ignace,
The $excludeFragment is `true` by default so in the example it should be
> `false` instead. Perhaps using an Enum instead would make the
> DX easier than using a boolean ?
> I believe the same issue is in all examples regarding the use of that
> parameter.
>
You are right, I completely
On Mon, Apr 28, 2025, at 3:30 PM, Tim Düsterhus wrote:
> Hi
>
> On 4/28/25 22:04, Larry Garfield wrote:
>> Holy cow, thank you for this bit. The inability to tell what went wrong
>> programmatically without string parsing the exception message is one of my
>> biggest pet peeves in current except
Hi Paul,
> The Rfc3986\Uri `raw()` methods present a departure from existing
userland expectations when working with URIs. No existing URI package that
I'm aware of retains the normalized values as their "main" values; the
values are generally retained-as-given (i.e. "raw"). Nor do they afford
get
Hi
On 4/28/25 22:04, Larry Garfield wrote:
Holy cow, thank you for this bit. The inability to tell what went wrong
programmatically without string parsing the exception message is one of my
biggest pet peeves in current exceptions.
Anything particular from the standard library? It might be
On Sun, Apr 27, 2025, at 4:45 PM, Tim Düsterhus wrote:
> 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 c
Hi Maté and all,
> On Apr 27, 2025, at 16:47, Máté Kocsis wrote:
>
> Hi Tim,
...
>> So it seems to be safer to use the naming without the `raw` and then in
>> the documentation explain what happens with useful examples, just like
>> the RFC already does.
>
> We discussed this off the list, an
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 Mon, Apr 28, 2025 at 9:05 AM ignace nyamagana butera
wrote:
> Hi Maté,
>
> I found another typo in the RFC examples due to the use of boolean as
> parameters
>
> // The fragment component of Uri\WhatWg\Url can also be taken into
> account$url = new Uri\WhatWg\Url("https://example.com#foo";);$
Hi Maté,
I found another typo in the RFC examples due to the use of boolean as
parameters
// The fragment component of Uri\WhatWg\Url can also be taken into
account$url = new
Uri\WhatWg\Url("https://example.com#foo";);$url->equals(new
Uri\WhatWg\Url("https://example.com";), true); // false
The $
19 matches
Mail list logo
