-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[API Proposal]: ArgumentException helper methods #77749
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
ThrowIfNullOrEmpty #62628 |
Tagging subscribers to this area: @dotnet/area-system-runtime Issue DetailsBackground and motivation#69590 describes adding helper methods to ArgumentOutOfRangeException, which is terrific. But there are a few more common helper methods that we use our source base which would be generally useful. API Proposalnamespace System.;
public class ArgumentException
{
/// <summary>
/// Throws either an <see cref="System.ArgumentNullException"/> or an <see cref="System.ArgumentException"/>
/// if the specified string is <see langword="null"/> or whitespace respectively.
/// </summary>
/// <param name="argument">String to be checked for <see langword="null"/> or whitespace.</param>
/// <param name="paramName">The name of the parameter being checked.</param>
/// <returns>The original value of <paramref name="argument"/>.</returns>
[return: NotNull]
public static string ThrowIfNullOrWhitespace([NotNull] string? argument, [CallerArgumentExpression("argument")] string paramName = "");
/// <summary>
/// Throws an <see cref="System.ArgumentNullException"/> if the string is <see langword="null"/>,
/// or <see cref="System.ArgumentException"/> if it is empty.
/// </summary>
/// <param name="argument">String to be checked for <see langword="null"/> or empty.</param>
/// <param name="paramName">The name of the parameter being checked.</param>
/// <returns>The original value of <paramref name="argument"/>.</returns>
[return: NotNull]
public static string ThrowIfNullOrEmpty([NotNull] string? argument, [CallerArgumentExpression("argument")] string paramName = "");
/// <summary>
/// Throws an <see cref="System.ArgumentNullException"/> if the collection is <see langword="null"/>,
/// or <see cref="System.ArgumentException"/> if it is empty.
/// </summary>
/// <param name="argument">The collection to evaluate.</param>
/// <param name="paramName">The name of the parameter being checked.</param>
/// <typeparam name="T">The type of objects in the collection.</typeparam>
/// <returns>The original value of <paramref name="argument"/>.</returns>
[return: NotNull]
public static IEnumerable<T> ThrowIfNullOrEmpty<T>([NotNull] IEnumerable<T>? argument, [CallerArgumentExpression("argument")] string paramName = "");
/// <summary>
/// Throws an <see cref="System.ArgumentException"/> if the argument's buffer size is less than the required buffer size.
/// </summary>
/// <param name="bufferSize">The actual buffer size.</param>
/// <param name="requiredSize">The required buffer size.</param>
/// <param name="paramName">The name of the parameter to be checked.</param>
public static void ThrowIfBufferTooSmall(int bufferSize, int requiredSize, string paramName = "");
} API UsageArgumentException.ThrowIfBufferTooSmall(destination.Length, source.Length); Alternative DesignsNo response RisksNo response
|
By the way, #69590 is waiting only @stephentoub final thoughts |
|
This issue has been marked |
This one already exists.
We've discussed this one multiple times in the past and had opted not to add it each time. We could reconsider if it's more commonly needed than we'd found at the time.
This seems like a pit of failure from a performance perspective. Developers will change code like: public void M(List<T> list)
{
if (list is null) throw new ArgumentNullException(...);
if (list.Count == 0) throw new ArgumentException(...);
...
} and replace it with: public void M(List<T> list)
{
ArgumentException.ThrowIfNullOrEmpty(list);
...
} and in doing so they just made their code more expensive, as the Count check would have been inlined as a simple field access, and now the code would need to do type tests, interface dispatch, etc. And then worse if the input wasn't an actual list, it's guiding developers to a pattern that leads to extra allocation from GetEnumerator. If the 99% case we care about is for arrays, we could consider a
Maybe? I'd be interested in seeing what that would look like around dotnet/runtime, how many places we'd actually end up using it, etc. |
Just to raise my voice, I am very much in favor of adding Yes, you can come around with |
It would be incredibly nice if there was a way to define custom guard methods that would work on the same exception types. Say: ArgumentException.ThrowIfMyCrazyScenarioMatchesHere(value); Would it be possible to push for extension methods to static classes to allow that? Otherwise, guard methods become all inconsistent: some are found in native exception classes, and some are part of a different type. This hurts discoverability and consistency a lot, or forces people to wrap the existing methods in new classes to ensure consistency (creating a lot of duplication). I understand this proposal would probably allow for this: However it will be incredibly unlikely to move forward as a single change where everything becomes extendable. Having just static extensions could be done with not as much effort, and would still be very useful in a lot of situations. Support for other types of extensions could follow later as they are independent from one another. |
I would also use ThrowIfNullOrWhitespace if it were available. |
What's the rationale for not wanting IfBufferTooSmall? I have an internal code base that can demonstrate an equivalent in action if examples are needed. About returning the input as a return value, again this is something we use throughout our code base. Could this be added to the other exception utility functions retroactively or is changing a void return considered a breaking change? |
It's a binary breaking change. The return type is part of the method identity; existing callers would start getting MissingMethodExceptions.
From above: |
public partial class ArgumentException
{
public static void ThrowIfNullOrWhiteSpace([NotNull] string? argument, [CallerArgumentExpression(nameof(argument))] string? paramName = null);
} |
EDIT 5/1/2023 by @stephentoub
The proposal suggested four methods:
The second already exists, the third is too expensive in its proposed form, and more validation would be needed on the fourth to conclude exactly what form it would take (e.g. someone trying it across .NET runtime and seeing what issues we might hit).
As such, I'm narrowing this down to just the first (which we've previously considered and rejected, but we've since received enough +1s that it's worth reconsidering):
public class ArgumentException { // existing public static void ThrowIfNullOrEmpty([NotNull] string? argument, [CallerArgumentExpression(nameof(argument))] string? paramName = null); + public static void ThrowIfNullOrWhiteSpace([NotNull] string? argument, [CallerArgumentExpression(nameof(argument))] string? paramName = null); }
To discuss:
Background and motivation
#69590 describes adding helper methods to ArgumentOutOfRangeException, which is terrific. But there are a few more common helper methods that we use our source base which would be generally useful.
API Proposal
API Usage
Alternative Designs
No response
Risks
No response
The text was updated successfully, but these errors were encountered: