ProAnswers.org

Why "as" operator so popular in C#?

In development blogs, online code examples and (recently) even a book, I keep stumbling about code like this:

var y = x as T; y.SomeMethod(); or, even worse:

(x as T).SomeMethod();

That doesn’t make sense to me. If you are sure that x is of type T, you should use a direct cast: (T)x. If you are not sure, you can use as but need to check for null before performing some operation. All that the above code does is to turn a (useful) InvalidCastException into a (useless) NullReferenceException.

Your understanding is true. That sounds like trying to micro-optimize to me. You should use a normal cast when you are sure of the type. Besides generating a more sensible exception, it also fails fast. If you’re wrong about your assumption about the type, your program will fail immediately and you’ll be able to see the cause of failure immediately rather than waiting for a NullReferenceException or ArgumentNullException or even a logical error sometime in the future. In general, an as expression that’s not followed by a null check somewhere is a code smell.

On the other hand, if you are not sure about the cast and expect it to fail, you should use as instead of a normal cast wrapped with a try-catch block. Moreover, use of as is recommended over a type check followed by a cast. Instead of:




	
		
			if (x is SomeType) 
			   ((SomeType)x).SomeMethod(); 
			 
	



which generates an [](http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.castclass.aspx) for the cast (effectively performing the cast twice), you should use:




	
		
			var v = x as SomeType; 
			if (v != null) 
			    v.SomeMethod(); 
			 
	



This only generates an isinst instruction. The former method has a potential flaw in multithreaded applications as a race condition might cause the variable to change its type after the is check succeeded and fail at the cast line. The latter method is not prone to this error.