Bytes2you.Validation – New Version Released (

With this post I want to share with you that a new version of Bytes2you.Validation library was just released.The release notes are as follows:

– Converted from ClassLibrary to PortableLibrary. Now it supports .NET Framework 4 and higher; Silverlight 4 and higher; Windows Phone 7 and higher; .NET for Windows Store apps; Xbox 360.
– Refactored the validation messages. Now every value is surrounded by <> for better readability.
– Introduced IsInstanceOfType() & IsNotInstanceOfType methods.
– Introduced IsNull() & IsNotNull() for Nullable<T> types.
– IntelliSense improvements. The members of IArgument<T> and IValidatableArgument<T> are now hidden from the editor.
– Added special float predicates – Infinity, NegativeInfinity, PositiveInfinity, NaN.
– Added special double predicates – Infinity, NegativeInfinity, PositiveInfinity, NaN.
– Better support for byte and short (no need to cast).

You can find the latest nuget here and the source code here.


Bytes2you.Validation – Defensive Programming Toolset


In my previous post I’ve talked about the defensive programming technique. As I’ve promised I’m sharing with you the required toolset for implementing defensive programming in .NET easily in your codebase in clear and testable way.


Bytes2you.Validatino is fast, extensible, intuitive and easy-to-use C# library providing fluent APIs for argument validation. It gives everything you need to implement defensive programming in your .NET applications.


The library is available in the NuGet Gallery here. Just type: PM> Install-Package Bytes2you.Validation


Guard.WhenArgument(argument, &quot;argument&quot;).Rule1().Rule2()...RuleN().Throw();

Based on the argument type there are different things that we can validate that make sense for that type (such as IsEmpty validation for string/guid/collection, etc.).

Examples: Instead of…

public void SomeMethod(string stringArgument)
   if (string.IsNullOrEmpty(stringArgument))
      throw new ArgumentException(&quot;Argument is null or empty string.&quot;, &quot;stringArgument&quot;);

   if (stringArgument == &quot;xxx&quot;)
      throw new ArgumentException(&quot;Argument is equal to \&quot;xxx\&quot;&quot;, &quot;stringArgument&quot;);

…we can use

public void SomeMethod(string stringArgument)
   Guard.WhenArgument(stringArgument, &quot;stringArgument&quot;).IsNullOrEmpty().IsEqual(&quot;xxx&quot;).Throw();
   // Which means - when stringArgument is null or empty OR is equal to &quot;xxx&quot; we should throw exception.

Rules List

Guard.WhenArgument&lt;T&gt;(argument, &quot;argument&quot;)

For all T:


When T is class:


When T is bool:


When T is IComparable:


When T is IEnumerable:


When T is Guid:


When T is string:


Fully Tested

The codebase is fully covered with unit tests (100% code coverage).

Excellent Performance

Performance tests are also presented ensuring that the library will not affect the performance of your applications.


One can easily add new rules (see ValidationRules namespace) and expose them through fluent API extensions (see FluentExtensions namespace).


I’ll be more than happy to hear your feedback about the aforementioned library. If you think of a way of improving it, or you believe that a new features will bring more value to it, you can just drop me a line.

Thank you!

Defensive Programming Technique: The Way to Fast Failure

Why One Will Want Not Only to Fail… But Also to Fail Fast?!?

Yep. At first it sounds wired. But let’s be honest with ourselves – no matter what we are doing or trying to do, failing is part of the game. Instead of pretending that we will never fail (which is 100% sure that won’t happen and makes failing fact rather than risk) we can do something better – to think of what is the best way to minimize the impact that fails will have on our software development projects. Also – when we fail this is opportunity to learn and to improve ourselves.

So given the fact that we will fail, when do we prefer to fail? In the beginning of a project when we have invested 2-3 weeks or at the end of the project when we have spent months or even years? When we put it that way the answer is more than obvious.

In this blog post we are going to present a programming technique that will help developers to fail fast – Defensive Programming.

The Software Developers’ Mindset

All software developers are optimists and so each one of us tends to ignore the reality that every line of code we write has a probability of being wrong. The probability may be lower for some of us than for others (we all think that) but it is never zero, and the consequence is that the bigger the program is the more certain it is to contain at least some bugs.

Most applications are not written by a single software developer, and so defensive programming also means defending your code against other people’s misuse of it. In an ideal world it should be obvious to others how to use the code we’ve written and this reduces the need for other forms of defense. However even where other people do not find the code obvious to use we should try to make it easy for them to understand what they have done wrong and how to get it right.

Definitions of Defensive Programming

There are quite a lot different definitions of what defensive programming is. Looking at some of them will give us a good context of “what” is it and “why” we should use it:

  • Wikipedia – Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software in spite of unforeseeable usage of said software. The idea can be viewed as reducing or eliminating the prospect of Murphy’s Law (“Anything that can go wrong, will go wrong.”) having effect. Defensive programming techniques are used especially when a piece of software could be misused mischievously or inadvertently to catastrophic effect.
  • PCMAG – Defensive programming means writing a secure program. Without security in mind, extensive validation of input is one area that is often overlooked. For example, if a small amount of data is expected as input, but the program accepts any amount, it provides a way for the cracker to insert executable code into the program. Using very clever hacking techniques, this code can be made to run.
  • Defensive Programming (Vesko’s definition) – programming technique that ensures (with code as part of the defended code!) that our classes, methods, properties, etc. are used in the way that we expect. Not only we are talking about hackers/crackers, but also we are talking about us and our colleagues who are and will be working with the provided APIs. Every one of us makes bugs but every one of us should always be eager to find and fix these bugs as soon as possible. In that way our code will fail fast and will cause potentially less damage.

Example of Defensive Programming Technique

For example imagine that we have ProductRepository class that has Delete(Product product) method. If we call it with null ProductRepository.Delete(null) what will happen? Probably some exception will be thrown right away (when trying to delete the product from the data source) and we will be able to see the exact cause of the problem.

Unfortunately there are cases which are not so straightforward – imagine that we set property to null when null does not make any sense for this property and we haven’t put any validation for such cases – public object Property { get; set; }. Later at some (indeterminate) point of time we try to use this property and our code will fail. What is the problem here? At that point of time we have bug (the given property is null), which is consequence of another bug – the call that has set this property to null? Instead of trying to figure it out from where this property is set to null we could just put a check in the setter that this property cannot be null.

public object Property
   if (value == null)
      throw ArgumentNullException(“Property”);
   this. property = value;

This small change will give us the ability to fail fast – we will be notified exactly when and where the Property is set to null and will be able to fix the real problem earlier and easily. A lot of other checks could be made – whether the given number is positive or in a given range, whether the passed string is/isn’t empty, etc.

But what should be checked? We should check everything that we can if we want to be really defensive. We should check input parameters of constructors, methods, property setters, etc. Should we validate parameters of private, internal methods? The short answer is yes, we should. We should because as we said earlier we are trying to defense our code not only from the public users/clients but also from ourselves. And yes – sometimes we will have cases that an argument is checked in a method and calls a method with the same argument where the argument is also checked. But that is not a problem. Each method should be “ready” to be called from everywhere and should not have any assumptions from where it is being called.

Up to now we have talked only for preconditions (how a method/constructor/property is called). What we should also check is some kind of post conditions. If at some point we need the result of something to be restricted in some way we should validate it. For example – if we call the method Product product  = GetProductByCode(productCode); and we know that this product must exist we should check it on the next line whether it is different from null.

In Conclusion…

We all fail. The only question is when we are going to fail. Are we going to fail in the beginning of development process? Or we are going to fail in the testing process? Or (worst case…) in the live environment? We should be eager to fail fast. The faster we fail the less damage will the fail cause. Using the defensive programming techniques will help us to go closer to this goal.

What’s Next?

The next thing that I’m going to present you is the needed toolset for implementing defensive programming easily in your codebase in clear and testable way.