Joe, The_Fruitman, Thanks for your response. Yes, the method of performing casts is definitely a matter of opinion and coding style. I clearly stated that this is the "way I prefer".
For the record, I am entirely unconvinced by the logic presented in John Wood's article and by your logic. I will comment inline : On May 21, 10:52 am, Joe Enos <[email protected]> wrote: > Basically, he's saying that if you know what it's supposed to be cast > to, then why not a direct cast? If it's not the type you were > expecting, then you probably would want to throw an > InvalidCastException, since obviously something went wrong. Any code I write stands out in one respect - It assumes nothing. I may be certain that the type of variable will be compatible with the type I am trying to cast it to. But I do not rely on that certainty. Ever. My code always checks for this compatibility and the best way to check this is to check nullability after attempting a cast that does not throw an exception. That's just the way I write my code so yes, it is a matter of personal style. I recommend it to others only because it rarely fails. And no, you probably **do not** want to throw an exception for code that frequently tries to attempt a cast. It is pretty well known and accepted that exceptions negatively impact performance. This the whole reason the Tester-Doer pattern exists and keywords such as TryCast(VB) and functions such as TryParse, TryGetValue exist. Also, you will not be the one throwing the exception, the CLR will be throwing the exception and you would only be catching it. Catching it would mean that you branch the flow of your code into the catch block, in order to maintain a semblance of recovering gracefully. > And if > you don't want to throw that exception, using the "is" statement in > advance works equally as well so you wouldn't even try the cast. The "as" keyword does already use the "is" type check. As the docs clearly state, --- expression as type --- is equivalent to: --- expression is type ? (type)expression : null --- So, it is a much cleaner and more efficient (not only is "expression" only evaluated once, you dispense with exception handling) way of type checking the variable first and then performing a cast. The "as" keyword performs only boxing and reference conversions. Therefore, the best case to use the keyword is the pretty common scenario when you need to cast an Object type into the actual runtime type. John Wood's only argument that I find to be valid is that you lose information on returning nulls. But no, my code never throws a NullReferenceException because I always check for nulls. On May 21, 7:03 pm, The_Fruitman <[email protected]> wrote: > Cerebrus: > > As Joe and the article he posted state, if the as keyword fails to > cast the item it returns an exception hidden behind a null return > value. I prefer to catch the InvalidCastException and handle it > accordingly. No, it does not return an exception at all. It simply returns a null and checking for null is relatively very inexpensive. I'm sure you prefer to handle the InvalidCastException when writing professional code, but you did not mention it in your post above (probably because a try-catch complicates the snippet when you are trying to make a simple point). By the same logic, the "as" keyword is so clean that you can include it in every example. > On May 20, 11:30 pm, Cerebrus <[email protected]> wrote: > > The_Fruitman: > > > The way I prefer is using the "as" keyword. It obviates the need to > > handle the InvalidCastException thrown in explicit casts: > > > TextBox txt1 = e.Item.FindControl("NameOfTextBox") as TextBox; > > if (txt1 != null) > > { > > // Successful cast. > > > } > > > I perform almost all casts using the as keyword. > > > On May 19, 6:58 pm, The_Fruitman <[email protected]> wrote: > > > > The way I've done it in the past is > > > TextBox txt1 = (TextBox)(e.Item.FindControl("NameOfTextBox")); > > > > Where e is type DataGridCommandEventArgs- Hide quoted text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text -
