The author shows that using “as” only returns a “NullReferenceException”, where a “()” cast returns an “InvalidCastException” and is a more useful error during debugging. But, he also shows where the “as” could be useful, since it silently returns a null value on failure.

Personally, I’ll take a slightly less “readable” line over potential irritation during debugging!

-Derek

Don’t get me wrong. I’m not for a moment advocating throwing an exception as part of any expected production execution path. I can’t imagine wanting to… so why worry about the ‘cost’?

The value of a well-placed exception though, for me, is that it identifies clearly to any consumer or modifier of a method that it has violated some contract. In other words, the programmer has made a mistake.

In this case, the code we’re working on takes a ‘widgetId’ (I should have called the parameter dooferId) which must be the Id of a doofer for the subsequent lines of code in the method to be meaningful and work.

We could re-write the first case like this:

Doofer doofer = GetWidget(dooferId) as Doofer;
if (doofer == null)
    throw new ArgumentException("dooferId","Must be the ID of a valid Doofer in the system");

That works, and maybe it’s more readable than my alternative. I’d have been happy if I’d seen that.