CuttingEdge.Conditions

Source code checked in, #94877

Project Collection Service Accounts — Mon, 01 Oct 2012 22:38:35 GMT

Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563

Source code checked in, #94876

Project Collection Service Accounts — Mon, 01 Oct 2012 22:31:06 GMT

Checked in by server upgrade

Source code checked in, #94109

dot_NET_Junkie — Tue, 28 Aug 2012 14:01:17 GMT

Projects upgraded from Visual Studio 2008 to 2010.

Reviewed: CuttingEdge.Conditions v1.2 (aug 10, 2012)

maartenmensink — Fri, 10 Aug 2012 11:05:54 GMT

Rated 5 Stars (out of 5) - This library is so easy to use it almost a crime not using it.

Commented Issue: Include Condition.Requires overloads with Func<> to get parameter name [17905]

dot_NET_Junkie — Mon, 23 Apr 2012 07:53:26 GMT

Your library is far superior to netfx.Guard apart from just one feature!

Condition.Requires() that you manually type the name for the parameter being checked.
netfx.Guard uses this syntax:

Guard.IsNotNull(() => paramName);

The parameter name is extracted automatically by visiting the expression tree.
Should be easy to implement!
Comments: ** Comment from web user: dot_NET_Junkie **

Such feature is indeed easy to implement, but I descided not to add such feature. You can read more about this here:
http://conditions.codeplex.com/discussions/278811

Commented Issue: Include Condition.Requires overloads with Func<> to get parameter name [17905]

georgiosd — Sun, 22 Apr 2012 23:51:19 GMT

Example:

public static void NotNull<TResult>(Expression<Func<TResult>> expression)
where TResult : class
{
if (expression.Compile()() == null)
{
var argName = GetParameterName(expression);
throw new ArgumentNullException(argName);
}
}

Commented Issue: Include Condition.Requires overloads with Func<> to get parameter name [17905]

georgiosd — Sun, 22 Apr 2012 23:50:29 GMT

Here's the code:

private static string GetParameterName(Expression reference)
{
var lambda = reference as LambdaExpression;
var member = lambda.Body as MemberExpression;

return member.Member.Name;
}

Created Issue: Include Condition.Requires overloads with Func<> to get parameter name [17905]

georgiosd — Sun, 22 Apr 2012 23:48:38 GMT

New Post: Custom exception from custom validator

bugmenot2 — Wed, 21 Dec 2011 09:30:39 GMT

Makes sense now, thanks

New Post: Custom exception from custom validator

dot_net_junkie — Tue, 20 Dec 2011 12:51:30 GMT

That sounds like right. Here's an example:

public static ConditionValidator<T> ThrowSomethingElse<T>(
    this ConditionValidator<T> validator)
{
    return new MyValidator<T>(validator.Value, validator.ArgumentName);
}

private sealed class MyValidator<T> : ConditionValidator<T>
{
    protected override void ThrowExceptionCore(string condition,
        string additionalMessage, ConstraintViolationType type)
    {
        throw new ArgumentFailureException(
            condition + ". " + additionalMessage); 
    }
}

Writing your own Validation method might be simpler, but this prevents you from using all the predefined validation methods that are already in the framework.

New Post: Custom exception from custom validator

bugmenot2 — Mon, 19 Dec 2011 20:27:13 GMT

So what you're saying:

* define a new validator "MyValidator<T>" which is a subclass of "ConditionValidator<T>"

* that subclass has a copy constructor which accepts an instance of the parent type as an argument

* "ThrowSomethingElse()" is an extension method on an instance of "ConditionValidator<T>"

* it returns a new instance of "MyValidator<T>"

* and... the subclass can throw custom exceptions

This approach is much more intuitive than that in the docs, I like it. But isn't simply throwing a custom exception from the custom validator simpler (surely I get access to the base class from my custom validator anyway)?

New Post: Custom exception from custom validator

dot_net_junkie — Mon, 19 Dec 2011 09:27:47 GMT

That will work. ThrowException is purely there to abstract the exception type that's being thrown.

Something else what you can do is define an extension method over ConditionValidator<T> that returns a new ConditionValidator<T> sub type. This way you can reuse all existing validation methods. You can do something like this:

Condition.Requires(val, "val").ThrowSomethingElse()
    .IsNotNull()
    .IsInRange(10, 99);

New Post: Custom exception from custom validator

bugmenot2 — Sun, 18 Dec 2011 23:03:47 GMT

There is an explanation in the docs, of how to add custom exceptions to the library: http://conditions.codeplex.com/wikipage?title=extending. It requires subclassing the "ConditionValidator<T>", which means that you cannot use "Condition.Requires()", but must use "CustomWhatever.Requires()", which I don't like.

Suppose I'd like to throw a "ArgumentFailureException" when my custom validator fails. So, in my custom validator, may I write:
throw new ArgumentFailureException("kaboom!");
instead of:
validator.ThrowException("kaboom!");

Will I break something in the library?

New Post: assert instead of throw

bugmenot2 — Sun, 04 Dec 2011 22:33:56 GMT

Yes seems good. Only in the ConditionAssert class I would set the flag explicitly, without considering the #DEBUG symbol (as that would be the purpose of that class).

Also, I'd refactor the ConditionValidator class to make the check itself, and avoid having to change the dozens of validators. Then I'd just call the protected validator method from the abstract base class' method. Something like so:

    public validate(...) {
       if (IsDebug) { ... }
       else { validateImpl(); }
    }

protected abstract validateImpl(); // implemented in the validator subclasses

Actually it seems like quite a neat implementation.

New Post: assert instead of throw

dot_net_junkie — Sun, 04 Dec 2011 18:53:36 GMT

For this to work, a boolean flag has to be added to the abstract ConditionValidator<T> class, and every single validation method should skip the check when the flag is set. In your local ConditionAssert class you must set this flag in debug mode to prevent any validations from being executed.

New Post: assert instead of throw

bugmenot2 — Sun, 04 Dec 2011 16:19:43 GMT

In theory, would the following work?
- add a debug/release flag in "ConditionAssert"
- check that flag in every validator, and throw/assert appropriately

There are dozens of validators, so it would be a PITA to refactor all of them--so is there a base class into which I could place that functionality? Could I do it in "ConditionValidator" and "ConditionValidator<T>", perhaps in the constructor?

New Post: assert instead of throw

dot_net_junkie — Sun, 04 Dec 2011 10:13:30 GMT

I'm sorry, but I made a mistake. The ConditionAssert class is utterly useless. What Debug.Assert (or [ConditionAttribute("DEBUG")] in general) is supposed to do is to remove the check completely, but this is not what happens. The only thing that will get suppressed in release mode is the throwing of the exception (or showing a dialog box, in the case of the Debug.Assert). The verification check itself however, is always executed.

It is this check that you normally want to prevent from happening, usually because of performance reasons. But since the check is always performed, it would be silly to suppress the throwing of the exception in release mode, since at that point we already established a bug in the software, and we’d better throw to prevent further damage to the system.

With the way CuttingEdge.Conditions is currently designed it is impossible to achieve this. Main reason for this is because both the entry point methods (Requires, Ensures) and the validation methods (IsNotNull, IsGreaterThan, etc) return a value. The C# and VB compilers will therefore not allow calls to those methods to be suppressed.

If you really want to suppress certain checks because of performance considerations, you’ve got two options:

1. Use #if DEBUG:

public void DoSomething(IEnumerable<Element> col)
{
#if DEBUG
    Condition.Requires("col").ContainsAll(requeredElements);
#endif
}

2. Move validation to another method:

public void DoSomething(IEnumerable<Element> col)
{
    ValidateArguments(col);
}

[Condition("DEBUG")]
private static void ValidateArguments(IEnumerable<Element> col)
{
    Condition.Requires(col, "col").ContainsAll(requeredElements);
}

I hope this helps.

New Post: custom validator: IsNotNullOrEmptyOrWhitespace

dot_net_junkie — Thu, 01 Dec 2011 19:07:20 GMT

Hehe.. you got me, it isn't cutting edge ;-).

I want Conditions to stay backward compatible for some time, or until there is a strong reason to go to .NET 4.0. But the IsNullOrWhiteSpace method alone doesn't seem like a valid reason to force a dependency on 4.0.

New Post: custom validator: IsNotNullOrEmptyOrWhitespace

bugmenot2 — Thu, 01 Dec 2011 19:00:11 GMT

Not use it! Why, I thought it was cutting edge?

Good point re versioning.

New Post: custom validator: IsNotNullOrEmptyOrWhitespace

dot_net_junkie — Thu, 01 Dec 2011 18:46:01 GMT

I must admit I find the IsNullOrWhiteSpace name not intuitive, but I decided to stick to that name in Conditions. Choosing the same name is less confusing, because now developers could at least expect the method to behave the same as the String.IsNullOrWhiteSpace method of the framework.

The String.IsNullOrWhiteSpace method is new in .NET 4.0, but CuttingEdge.Conditions is for .NET 2.0 and up and therefore cannot take a dependency on .NET 4.0 functionality. That's why it does the char-by-char check itself, instead of depending on String.IsNullOrWhiteSpace. I don't really think that the framework's implementation will ever be much faster than it currently is, so I don't think that's something you should really worry about. If you worry about that kind of optimizations, perhaps using CuttingEdge.Conditions isn't a wise thing in the first place ;-).

Cheers