As I pointed already in another PR, this generates worst code.
Also in .Net 8 Preview 1 we will get ArgumentOutOfRangeException.ThrowIfZero (and more) so that the code will be:

ArgumentNullException.ThrowIfNull(value, paramName);
ArgumentNullException.ThrowIfZero(value.Count);

The difference in generated code doesn't always matter, and you cannot use it as the single criteria. In this case, the original code is more readable.

As far as I can found in the dotnet/runtime repo, it's ArgumentOutOfRangeException.ThrowIfZero, not ArgumentNullException.ThrowIfZero. It throws a different exception.
Also, even in case of ArgumentOutOfRangeException.ThrowIfZero(value.count), I don't know what will be used as the parameter name, "value.count" I guess?

You are right it will throw a different exception, I don't know if it will be a problem (maybe we just have to change the tests).

From dotnet/runtime#69590
public static void ThrowIfZero<T>(T value, [CallerArgumentExpression("value")] string? paramName = null) it seems can set any string as parameter name

The original code is not correct. There are not too few places in our code where an exception is called that is not what it should be. This is not even a breaking change, as it is not a functional exception, and it is worth correcting it for the correct one. If someone even uses this behavior in their code, it is catastrophically bad code.

I don't know what will be used as the parameter name, "value.count" I guess?

Yes, as the attribute name (CallerArgumentExpression) says expression is used as "name". It is more informative and more correct. (Otherwise this API would never have been approved.)

So I think we should fix such protective (non-functional) exceptions to the correct ones in whole code base.

So I think we should fix such protective (non-functional) exceptions to the correct ones in whole code base.

That will need to be discussed and approved by all maintainers. If you insist on fixing those exceptions, then please open an issue on it and mark it with Review - Maintainer.

ArgumentOutOfRangeException won't be the right exception either. If you insist to be accurate about the exception, then an ArgumentException with a customized error message should be the way to go.

In my personal view, changing those exceptions is not worth the time (discussion, making the change, and code review). But if all other maintainers agree to make the change, then I'm fine to replace the current code with a customized ArgumentException.

I already explained in #19151 (comment) why it's arguably incorrect. I'm not trying to persuade you, just to clarify my opinion.

I'm trying to figure out what to demand from other contributors so we don't waste time later. So you'd better convince me. 😃
Right now I don't see that a ArgumentException message would be better than an ArgumentOutOfRangeException. (If I understand correctly you have no objection to the exception class type used but only to content of message.)
While I'm on vacation and have no opportunity to experiment. I'll try it a week later.

A custom message will be absolutely better than 'paramName' must be a non-zero value. (Parameter 'paramName'), which is what ArgumentOutOfRangeException.ThrowIfZero gives you.

In this particular case, the message should be something like 'paramName' must be a non-empty collection. (Parameter 'paramName')

you have no objection to the exception class type

I'm fine changing the type of exception to be thrown. That's a bucket 3 breaking change.

I took a look at the history of this API. It was created by Stephan Toub and updated by him. It is hard to suspect him of negligence. I think this is intentional since the exact API was rejected as I mentioned above. So after a while this pattern may become a frequently used one.

To be clear, ClientWebSocketOptions.SetBuffer(Int32, Int32, ArraySegment<Byte>) is a public API introduced in .NET Framework 4.5. In any case, please could we should start discussion in a new issue.

I took a look at the history of this API. It was created by Stephan Toub and updated by him. It is hard to suspect him of negligence. I think this is intentional since the exact API was rejected as I mentioned above. So after a while this pattern may become a frequently used one.

To be clear, ClientWebSocketOptions.SetBuffer(Int32, Int32, ArraySegment<Byte>) is a public API introduced in .NET Framework 4.5. In any case, please could we continue discussion in a new issue.