Firstly, I tried to research if this had been proposed and did not find an existing issue. Of course, if one exists, please link to existing and close.
I am aware that this usage can be captured by ArgumentOutOfRangeException, but these cases are so common that the System.String class itself has methods for just these checks, and they can provide a more specific default message when used like:
new ArgumentNullOrEmptyException(nameof(strParmeter));
then ArgumentNullException or ArgumentOutOfRange does.
My proposal is that these would be subclasses of ArgumentOutOfRangeException.
Of course, the momentum behind just using ArgumentOutOfRangeException may be so great to preclude the usefulness of such classes, but I believe the overall use cases they cover is common enough to warrant consideration.
In terms of answering the question "what went wrong that caused this exception?" then it would seem that ArgumentNullException, ArgumentOutOfRangeException or another exception derived from ArgumentException would always be at least as good, and potentially better.
In terms of catching, I can't see that one would often want to catch ArgumentNullOrEmptyException and not catch ArgumentException.
As a shortcut to the thrower, if you don't care to distinguish between them, why not just throw ArgumentException?
Also changing a method to throw ArgumentNullOrEmptyException would be a breaking change since it can't derive from both of the individual ones. It would need a good reason to do it and I don't see that.
@ndykman I don't this one is going to be an acceptable breaking change (or useful enough) unfortuntaely. Thanks for the suggestion, though. Others are welcome!
Most helpful comment
In terms of answering the question "what went wrong that caused this exception?" then it would seem that
ArgumentNullException,ArgumentOutOfRangeExceptionor another exception derived fromArgumentExceptionwould always be at least as good, and potentially better.In terms of catching, I can't see that one would often want to catch
ArgumentNullOrEmptyExceptionand not catchArgumentException.As a shortcut to the thrower, if you don't care to distinguish between them, why not just throw
ArgumentException?