If we suddenly start to throw a different exception, wouldn't this break existing code that catches the "old" exception?

Hi @derrabus ,

If we suddenly start to throw a different exception, wouldn't this break existing code that catches the "old" exception?

That's a great question.

No, it wouldn't break, since it has never been released.

That's why I'm opening this PR now, so that these two exceptions won't create backward compatibility promise starting from 7.3 and onward.

Yes, it is not released yet

it's possible to determine whence the exception originated from by checking its getFile, or checking the trace.

This doesn't look like a good practice to me, so this sounds like a counter argument.

What benefit do you expect from this PR over the current situation?

Coincidentally, php-src is working on php/policies#17, that might give some food for thoughts on the topic.

Specifically, I want to unify what exceptions are thrown form uid-classes.

What I mean is following:

• If you call Uuid::fromBase32(), currently you might get InvalidArgumentException, or InvalidUuidException;
• If you call Ulid::fromBase32(), currently you might get InvalidArgumentException, or InvalidUlidException;

I want to unify it all so that whether you call Uuid::fromBase32(), or Ulid::fromBase32(), you'll get the same InvalidUidException that is related to AbstractUid rather than to any concrete implementation.

Benefit is that InvalidUidException is conceptually self-evident - it is thrown when creating uid.

I am not in favor of this change. If one wants to only care for one exception than for either InvalidUuidException or InvalidUlidException that's already possible by catching InvalidArgumentException instead. For anyone wanting to distinguish UUID and ULID having distinct exceptions is better.

One can not distinguish between Uuid::fromBase32() and Ulid::fromBase32() (and fromBinary, fromBase58, fromRfc4122 as well) since these might fail due to the length check is in AbstractUid:

public static function fromBase32(string $uid): static
{
    if (26 !== \strlen($uid)) {
        throw new InvalidArgumentException($uid, 'Invalid base-32 uid provided.');
    }

    return static::fromString($uid);
}

So then it's not possible to distinguish anyway.

I am not in favor of this change.

As far as I remember, you were not in favor of the exceptions being introduced either.

Also, I remember @nicolas-grekas was for the idea to have one single InvalidUidException, while I stated that it's better to have them separate.

Now, I revised the code and see that it's better to have the unified interface so that make fromBinary, fromBase58, fromBase32, fromRfc4122 (actually any method that creates uid) throw it. It's totally clear from UI standpoint that InvalidUidException is thrown due to the creation

Hi guys, I would like to move on if you don't mind

I'm AFK until next week, I'll come back here ASAP.

Sure, have a nice time

Just want to make sure this doesn't get off to 7.3 release

It's a small change, I think it mustn't need much work

@nicolas-grekas , @fabpot , just a quick check-in, since I don't want to introduce BC promise for 7.3, is it all right right?