{"id":5037,"date":"2023-09-11T12:17:55","date_gmt":"2023-09-11T17:17:55","guid":{"rendered":"https:\/\/neosmart.net\/blog\/?p=5037"},"modified":"2023-09-11T13:05:56","modified_gmt":"2023-09-11T18:05:56","slug":"callerargumentexpression-and-extension-methods-dont-mix","status":"publish","type":"post","link":"https:\/\/neosmart.net\/blog\/callerargumentexpression-and-extension-methods-dont-mix\/","title":{"rendered":"CallerArgumentExpression and extension methods don’t mix"},"content":{"rendered":"

\"\"This post is for the C# developers out there and takes a look at the interesting conjunction of [CallerArgumentExpression]<\/code> and static extension methods \u2013 a mix that at first seems too convenient to pass up.<\/p>\n

A quick recap: [CallerArgumentExpression]<\/code> landed<\/a> as part of the C# 10.0 language update and helps to reduce the (often brittle!) boilerplate involved in, among other uses, creating useful error messages capturing the names of variables or the text of expressions. You tag an optional string<\/code> method parameter with [CallerArgumentExpression(\"argName\")]<\/code> where argName<\/code> is the name of the method argument you want stringified, and the compiler does the rest.<\/p>\n

<\/p>\n

Here’s a quick demo of how [CallerArgumentExpression]<\/code> works:<\/p>\n

using System;\r\nusing System.Runtime.CompilerServices;\r\n\r\npublic class Program\r\n{\r\n    static string Stringify(object obj,\r\n        [CallerArgumentExpression(\"obj\")] string expr = \"\")\r\n    {\r\n        return expr;\r\n    }\r\n\r\n    public static class Foo\r\n    {\r\n        public string Bar = \"bar\";\r\n    }\r\n\r\n    public static void Main()\r\n    {\r\n        var expr = Stringify(Foo.Bar);\r\n        Console.WriteLine(expr); \/\/ prints \"Foo.Bar\"\r\n        expr = Stringify(Foo.Bar + Foo.Bar);\r\n        Console.WriteLine(expr); \/\/ prints \"Foo.Bar + Foo.Bar\"\r\n    }\r\n}\r\n<\/code><\/pre>\n
And you can try it online yourself in this .NET Fiddle<\/a>.<\/p>\n
It’s really cool and it opens the door to a lot of possibilities (though I’m still stuck trying to figure some of them out, such as reliably setting\/clearing model binding errors that involve array expressions).<\/p>\n
As mentioned, this shipped with C# 10. And of course, C# 8 shipped “the big one:” nullable reference types<\/a>. Since then, the following pattern has become familiar in many a codebase while devs figure out where variables actually can or can’t be null:<\/p>\n
using System;\r\nusing System.Diagnostics.CodeAnalysis;\r\nusing System.Runtime.CompilerServices;\r\n\r\nstatic class Extensions\r\n{\r\n    public static T ThrowIfNull<T>([NotNull] T? value, string expr)\r\n    {\r\n        if (value is null) {\r\n            throw new ArgumentNullException(expr);\r\n        }\r\n        return value;\r\n    }\r\n}\r\n<\/code><\/pre>\n
This does exactly what you think it does: it verifies that a value isn’t null or throws an exception if it is. And it lets the compiler know that downstream of this call, the passed-in value is non-null<\/code>. To make it useful, it’s common enough to extend it with more caller attribute magic:<\/p>\n
using System;\r\nusing System.Diagnostics.CodeAnalysis;\r\nusing System.Runtime.CompilerServices;\r\n\r\nstatic class Extensions\r\n{\r\n    public static T ThrowIfNull<T>(\r\n        [NotNull] T? value,\r\n        string expr,\r\n        [CallerMemberName] string callerName = \"\",\r\n        [CallerFilePath] string filePath = \"\",\r\n        [CallerLineNumber] int lineNumber = 0)\r\n    {\r\n        if (value is null) {\r\n            throw new InvalidOperationException(\r\n                $\"{expr} unexpectedly null in {callerName} \"\r\n                + $\"at {filePath}:{lineNumber}\");\r\n        }\r\n        return value;\r\n    }\r\n}\r\n<\/code><\/pre>\n
Now we get useful exceptions that we’ll hopefully log and revisit to help us find any places in our codebase where we are assuming a value can’t be null<\/code> but it turns out that, in fact, it can be.<\/p>\n
But what about if we try to add our new best buddy [CallerArgumentExpression]<\/code> here, to get rid of the need to manually specify the text of the argument via argName<\/code> in our ThrowIfNull()<\/code>?<\/p>\n
using System;\r\nusing System.Diagnostics.CodeAnalysis;\r\nusing System.Runtime.CompilerServices;\r\n\r\nstatic class Extensions\r\n{\r\n    public static T ThrowIfNull<T>(\r\n        [NotNull] T? value,\r\n        [CallerArgumentExpression(\"value\")] string expr = \"\",\r\n        [CallerMemberName] string callerName = \"\",\r\n        [CallerFilePath] string filePath = \"\",\r\n        [CallerLineNumber] int lineNumber = 0)\r\n    {\r\n        if (value is null) {\r\n            throw new InvalidOperationException(\r\n                $\"{expr} unexpectedly null in {callerName} \"\r\n                + $\" at {filePath}:{lineNumber}\");\r\n        }\r\n        return value;\r\n    }\r\n}\r\n<\/code><\/pre>\n
At first blush, this works great. Use it with a single variable directly, as in foo.ThrowIfNull()<\/code>, and everything will work swimmingly and it’ll do exactly what it says on the tin. But try using it in a more-complicated setting, say like foo?.bar?.ThrowIfNull()<\/code>, and you’ll see what I mean: here, argName<\/code> will only capture the last token in the chain and you’ll see that argName<\/code> is only bar<\/code> and not foo.bar<\/code>!<\/p>\n
It’s actually not particularly surprising behavior. Even without knowing what Roslyn desugars the above code to, you could logically think of it as being an expression (conditionally) invoked on\/with the final variable bar<\/code> itself \u2013 after all, T<\/code> here would have been bar.GetType()<\/code>, so it’s not a huge stretch of the imagination to guess that expr<\/code> might only span bar<\/code> as well.1<\/a><\/sup><\/p>\n
Indeed, when you look at what the code compiles to, you’ll see why. For the following code fragment:<\/p>\n
public class Foo {\r\n    public string? Bar;\r\n}\r\n\r\npublic class C {\r\n    public void M(Foo? foo) {\r\n        foo?.Bar.ThrowIfNull();\r\n    }\r\n}\r\n<\/code><\/pre>\n
We get<\/a><\/p>\n
public class Foo\r\n{\r\n    [System.Runtime.CompilerServices.Nullable(2)]\r\n    public string Bar;\r\n}\r\n\r\npublic class C\r\n{\r\n    [System.Runtime.CompilerServices.NullableContext(2)]\r\n    public void M(Foo foo)\r\n    {\r\n        if (foo != null)\r\n        {\r\n            Extensions.ThrowIfNull(foo.Bar, \".Bar\");\r\n        }\r\n    }\r\n}\r\n<\/code><\/pre>\n
Which, while still helpful, is not exactly what we want. Although as C# developers we are somewhat allergic to calling static helper utilities directly instead of cleverly turning them into their more ergonomic extension method counterparts, in this we don’t have any other choice.<\/p>\n
When we change ThrowIfNull()<\/code> from an extension method to a regular static method though, we get the result we really<\/em> wanted:<\/p>\n
public static class Utils\r\n{\r\n    public static T ThrowIfNull<T>(\r\n        [NotNull] T? value,\r\n        [CallerArgumentExpression(\"value\")] string? expr = null) \r\n    {\r\n        if (value is null) {\r\n            throw new ArgumentNullException(expr);\r\n        }\r\n        return value;\r\n    }\r\n}\r\n\r\npublic class Foo\r\n{\r\n    public string? Bar;\r\n}\r\n\r\npublic class C\r\n{\r\n    public void M(Foo? foo)\r\n    {\r\n        Utils.ThrowIfNull(foo?.Bar);\r\n    }\r\n}\r\n<\/code><\/pre>\n
Desugaring to<\/a>:<\/p>\n
public class C\r\n{\r\n    [System.Runtime.CompilerServices.NullableContext(2)]\r\n    public void M(Foo foo)\r\n    {\r\n        Utils.ThrowIfNull((foo != null) ? foo.Bar : null, \"foo?.Bar\");\r\n    }\r\n}\r\n<\/code><\/pre>\n
Liked this post? Follow me on twitter @mqudsi<\/a> and like this tweet for more .NET awesomeness!<\/p>\n
\n
Do you know how to effectively use [CallerArgumentExpression] to supercharge C# @dotnet<\/a> codebase? Here's the number one mistake to look out for. https:\/\/t.co\/sReLDSS3iw<\/a><\/p>\n
— Mahmoud Al-Qudsi (@mqudsi) September 11, 2023<\/a><\/p><\/blockquote>\n