notes from a passionate developer





This is a personal blog. The opinions expressed here represent my own and not those of my employer, nor current or previous. All content is published "as is", without warranty of any kind and I don't take any responsibility and can't be liable for any claims, damages or other liabilities that might be caused by the content.

Ensure.That updates

Ensure.That has been around for quite some time (2011-08-23). With the new release (v7.0.0) there are some changes, e.g. targeting .NET Standard 1.1 & 2.0 as well as .NET4.5.1 and a new contextual API. But it's also time to finally deprecate the old API lurking around in there, namely the Ensure.That flavor. So instead of:

Ensure.That(myValue, nameof(myValue)).IsNotNullOrEmpty();

You should instead start using one of the flavors shown below.

Using contextual validation

Ensure.String.IsNotNullOrWhiteSpace(myString, nameof(myArg));

the value is passed through so that you e.g. can assign it to a field:

_field1 = Ensure.String.IsNotNullOrWhiteSpace(myString);
_field2 = Ensure.String.IsNotNullOrWhiteSpace(myString, nameof(myArg));

Using static simple methods

EnsureArg.IsNotNullOrWhiteSpace(myString, nameof(myArg));

the value is passed through so that you e.g. can assign it to a field:

_field1 = EnsureArg.IsNotNullOrWhiteSpace(myString);
_field2 = EnsureArg.IsNotNullOrWhiteSpace(myString, nameof(myArg));

Why am I removing it?

One reason is: "I don't use that flavor my self anymore and do not want to maintain three flavors.". The reason for me not using it is that the Ensure.That construct creates a new instance of Param<T> or Param every time you call it. Maybe this isn't that big of an deal for a few calls, but used in a loop where lots of values are being passed to a method that operates on these values after validating the input args... So, with this in mind, it's been marked as Obsolete generating a warning and will be removed in the next major version.

Another reason is, that the Ensure.That(..., ...) flavor allowed you to extend exception messages etc. Even throw completely other exceptions. This kind of goes against the intentions of being a simple and somewhat opinionated and just be about argument validation. The exception messages should be good enough. If not, feel free to issue a pull request. They are intended for devs/ops in logs etc. not for bubbling up to end users.

Feel free to disagree. And if you strongly disagree, feel free to fork, adapt and publish under a new name.



View Comments