Many thanks to the sponsors who make it possible for this newsletter to be free for readers.

• If you have ever used Postman to debug and write tests for your REST APIs, guess what, those are the same concepts you need to know for writing tests for your gRPC requests in Postman. For more info about gRPC, they created a great beginner article here.

• Renowned author Mark Price is your guide through the latest in .NET development, covering essential technologies like Blazor Full Stack, ASP.NET Core MVC, .NET MAUI, and more! Explore the intricacies of gRPC, GraphQL, SQL Server, Cosmos DB, SignalR, Azure Functions, and beyond. Elevate your skills with confidence. Check the book here.

The Background

Guard clauses in .NET are a programming practice used for improving the readability and reliability of code. They are simple checks at the beginning of a function or a method that validate inputs or conditions before proceeding with the rest of the code.

Guard clauses in .NET effectively address several common programming problems: they reduce complexity and increase readability by preventing deeply nested code structures; enhance code safety and reliability by validating inputs or conditions at the outset, thus averting potential runtime errors or unexpected behavior; and they clarify the code's intent by explicitly stating the preconditions needed for subsequent code to execute correctly.

This not only makes the code easier to understand but also simplifies maintenance and future modifications, as the requirements and constraints are clearly laid out at the beginning of the method or function.

How to implement it?

Let's take a look deeply!

Without Custom Guard Clause 

Under normal circumstances, this would be a common piece of code you would see in an application.

public class Person
{
    public string Name { get; private set; }

    public Person(string name)
    {
        if (string.IsNullOrEmpty(name))
        {
            throw new ArgumentException("Name cannot be null or whitespace.", nameof(name));
        }

        Name = name;
    }
}

There is nothing unknown here. We check if the name is filled in and throw an exception if it is not.

Note: I am not a supporter of this practice that exceptions are thrown in situations when it is not necessary. In this case, I would use the Result object with the Failure status. Certainly, this issue is about another problem that we are solving, so we will stick to exceptions.

What's wrong here?

Nothing specific. But code readability is not something.

Just imagine, let's now insert another check for us (is it in the right format, good length, etc...). The function will have 20 lines of code just for checking.

Let's make it sexier... :)

Custom Guard Clause

We will create a static class Ensure. I like to call it that, so that one can immediately conclude what it is about.

Within it, we will add the first method that the class will check.

This code will actually read in English:.

public static class Ensure
{
    public static void NotNullOrEmpty(string? value,
        string? paramName = null)
    {
        if(string.IsNullOrEmpty(value))
        {
            throw new ArgumentException("The value can't be null", 
            paramName);
        }
    }
}

If this is the case, the job and responsibility of throwing the exception is taken over by the Guard Clause class.

In this way, we have a clean and legibly written method.

We can see that below:

public Person(string name)
{
    Ensure.NotNullOrEmpty(name);

    // Logic
}

Use a help of CallerArgumentExpression 

Instead of constantly passing the name of the parameter for which an exception is thrown, which was passed as paranName in the NotNullOrEmpty() function, you can use the attribute CallerArgumentExpression("value") , where value represents the attribute for which we need a name.

What will happen?

At runtime, this value will be read and assigned to the paramName attribute.

This can be very useful in many situations, and we avoid hardcoding the parameter names and the potential error of writing the wrong parameter.

Take a look here:

public static class Ensure
{
    public static void NotNullOrEmpty(string? value, 
        [CallerArgumentExpression("value")] string? paramName = null)
    {
        if(string.IsNullOrEmpty(value))
        {
            throw new ArgumentException("The value can't be null", 
            paramName);
        }
    }
}

Check these libraries

Today I did not invent electricity like Nikola Tesla.

Many developers have already created quality libraries for the same purpose.

You can see some of them on the following links:

• Ardalis

• Dawn

• Throw

Whichever you choose, you won't have any problems. And if you want more control, you can always create your own custom, as I showed.

Wrapping up

In today's issue, I showed you how to improve readability and shift the responsibility of throwing exceptions (if necessary) to another class that should handle it.

And in this way, you will increase the readability of your method that deals with logic. By using Guard Clauses.

I showed you how to create your own Custom Guard Clause.

I explained what the CallerArgumentExpression attribute is and how to use it.

And finally, if you wouldn't do it, I gave you an example of 3 existing libraries that do it in an excellent way.

That's all from me today.