Hi, Habr! There are several ways to validate arguments. For example, to check for null you can use:

1. if (! ReferenceEquals (arg, null)) throw ...
2. Code Contracts : Contract.Requires (! ReferenceEquals (arg, null))
3. Guard.IsNotNull (arg, nameof (arg))

In the article I will consider only the third option (all code samples are for C #, however some of them will be useful in Java).

Error number 1: not prepared for the checks of the arguments and in the body of the method

Most often in a project, to eliminate copying of the same code, someone creates a static class in which you can check the field for null, more than zero, etc.

However, in this case it is forgotten that one and the same verification can be extremely useful for validating arguments (in this case, the name of the argument is passed as an additional parameter), and for checking inside the method (in this case, another exception is thrown).

So, for a start it is best to agree in advance on the naming of both cases. For example, Guard.IsNotNull for the body of the method and Guard.ArgumentIsNotNull for the arguments

Error number 2: call string.format with each check

Immediately examples of erroneous code:

 Guard.IsNotNull(connection, $"Unable to setup connection with host {host} and port {port}") Guard.IsNotNull(connection, string.Format("Unable to setup connection with host {0} and port {1}", host, port)) //      

Both examples above generate a string for each check (in theory, all Guard do not throw exceptions on the combat server, that is, we generate quite a few lines just to be eaten by the garbage collector).

Corrected version:

 public static class Guard { public static void IsNotNull(object value, string format, params object[] formattingArgs) //        ,            } 

In fact, the option above is also bad. It does not create a string anymore, but for each method call a new array formattingArgs is created. Of course, less memory is allocated for it, but such methods will still load on the garbage collector.

The most annoying thing is that the program will slow down, but simple profiling will not cause a problem. Your program will simply stop to clear memory more often (I fixed this error in one of the programs, garbage collection began to occupy instead of the previous 15% only 5%).

So, we proceed in the same way as done in string.Format : we generate more methods for different numbers of arguments.

 public static class Guard { public static void IsNotNull(object value, string errorMessage) public static void IsNotNull(object value, string errorMessageFormat, object arg1) public static void IsNotNull(object value, string errorMessageFormat, object arg1, object arg2) public static void IsNotNull(object value, string errorMessageFormat, object arg1, object arg2, object arg3) } 

So, now the array will not be allocated. However, we automatically received a new problem - Boxing.
Consider the method call: Guard.IsNotNull(connection, "Unable to setup connection with host {0} and port {1}", host, port) . The variable port is of type int (most often at least).

It turns out that in order to pass a variable by value, .Net will create an int each time on the heap to pass it as an object. This situation will occur much less frequently, but it will still be.

And another problem - if the original object being checked is the value type (for example, we check for null in a generic method that has no type restrictions).
You can fix this by creating Generic methods for checks:

 public static class Guard { public static void IsNotNull<TObject>(TObject value, string errorMessage) public static void IsNotNull<TObject, TArg1>(TObject value, string errorMessageFormat, TArg1 arg1) public static void IsNotNull<TObject, TArg1, TArg2>(TObject value, string errorMessageFormat, TArg1 arg1, TArg2 arg2) public static void IsNotNull<TObject, TArg1, TArg2, TArg3>(TObject value, string errorMessageFormat, TArg1 arg1, TArg2 arg2, TArg3 arg3) } 

Error number 3: no code generation

As can be seen above, in order to conveniently check the values ​​for null, we need:

1. Create two sets of functions - for checking the arguments and for checking in the body of the method
2. In each set - create a bunch of duplicates, which will contain the same code

Without code generation, it is relatively difficult to add new functions, much less change them.

More improvements

The points below do not speed up your program, but just slightly improve readability.

ReSharper Annotations

Often ReSharper swears that the value may be null, although it seems to be checked with the help of Guard. In this case, you can either start gradually to block warnings in the code (which may be fraught), or explain to the verifier that everything is fine. The full list of attributes can be viewed here , but here are useful for us:

• AssertionMethodAttribute and AssertionConditionAttribute - the two of them will explain to the system that the method only checks the argument, and at the same time they will write down what they are checking
• NoEnumerationAttribute - shows that if you pass an IEnumerable to the input, then nobody will iterate over it
• CollectionAccessAttribute - if you suddenly decide to check all the arguments of the collection (for example, that there are no more than five, and that they are not null), then using this attribute you can tell what exactly happens to the collection (read, write, etc.)
• StringFormatMethodAttribute - explains that one of the parameters is a string, which will then be used as a format. In this case, it will additionally be checked that it can be parsed by string.Format, that the number of arguments corresponds to the expectations, etc. Incidentally, I have not yet seen a project in which this check would be disabled, and in which, after it was turned on, there would be no errors that string.Format simply could not be executed

Record more information

In theory, the number of exceptions to our functions on combat servers should be the smallest. Consequently, any actuation of them should carry a maximum of information: what actually happened (after all, the situation is rare). At a minimum, it is best to include in the text:

1. Type (or better call ToString from him), which turned out to be incorrect.
2. If there are more arguments for comparison, then information about them too.
3. Full stacktrace (because otherwise it is trimmed to the place where the exception was caught)

Conclusion

I hope this article will help you to relatively easily improve the checks in your code.
A little earlier, I implemented all the developments in the library (source code under the MIT license) - so you can just use it (or copy the code to yourself, etc.)