Explain this to me
-
Ista wrote: What does the as keyword do here is it the same as type casting with the parentheses? The basic idea is the "as" keyword does the same thing as casting except if the object can't be cast it won't throw an error, it will return null so you might want to do something like:
Customer singleCustomer = new Customer();
PropertyManager pm = this.BindingContext[singleCustomer] as PropertyManager;
if(pm != null)
//... continue on with pm-Nick Parker
There are somethings we are bound to miss, but I have a hard time beleiving, I missed this one. Did not pay attention to the usefulness of "AS"... Tanx! Rocky Moore <><
-
So is that bad programming practice and should only be used in strictly sure cases or it doesnt really matter? I'm not an expert yet, but I play one at work. Yeah and here too.
Ista wrote: So is that bad programming practice and should only be used in strictly sure cases or it doesnt really matter? There isn't a problem with it as long as you are confirming the cast was performed without returning a null value. If you don't check for a null value and the cast returns a null, accessing your object will then throw a
NullReferenceException. -Nick Parker -
There are somethings we are bound to miss, but I have a hard time beleiving, I missed this one. Did not pay attention to the usefulness of "AS"... Tanx! Rocky Moore <><
:-D -Nick Parker
-
There are somethings we are bound to miss, but I have a hard time beleiving, I missed this one. Did not pay attention to the usefulness of "AS"... Tanx! Rocky Moore <><
Well, if your research patterns are anything like mine, you mainly concentrated on the things things that you needed to get the job done, and therefore skipped some of the extras, like this one. ;)
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
Well, if your research patterns are anything like mine, you mainly concentrated on the things things that you needed to get the job done, and therefore skipped some of the extras, like this one. ;)
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhijdunlap wrote: Well, if your research patterns are anything like mine, you mainly concentrated on the things things that you needed to get the job done, and therefore skipped some of the extras, like this one. Just remember, it all maybe useful sometime down the road, mental bookmarks do it for me. :) -Nick Parker
-
jdunlap wrote: Well, if your research patterns are anything like mine, you mainly concentrated on the things things that you needed to get the job done, and therefore skipped some of the extras, like this one. Just remember, it all maybe useful sometime down the road, mental bookmarks do it for me. :) -Nick Parker
Yes. Speaking of research patterns: What I find best is to investigate the technologies you come across just enough to get a feel for what they do and what they would be good for. Then learn in detail the technologies relative to the projects you work on. If you happen to need a certain functionality, your "shallow research" will have given you the knowledge you need to narrow down your search to the technologies that will fit the new need.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
There are somethings we are bound to miss, but I have a hard time beleiving, I missed this one. Did not pay attention to the usefulness of "AS"... Tanx! Rocky Moore <><
Well I kind of like the as even though it resembles vb code. I'm used to type casting in c++ where I constantly check for null values but I would much rather throw an exception. But then again exceptions in .NET are very costly and therefore as would work better. But then again if your not using reflection you should know what the object was and it would be easier to test for null. I guess would say the () is better in that it throws an exception unless it is a popular function in that case I would use as to keep it running fast. My opinion, critices and comments welcome nick I'm not an expert yet, but I play one at work. Yeah and here too.
-
Well I kind of like the as even though it resembles vb code. I'm used to type casting in c++ where I constantly check for null values but I would much rather throw an exception. But then again exceptions in .NET are very costly and therefore as would work better. But then again if your not using reflection you should know what the object was and it would be easier to test for null. I guess would say the () is better in that it throws an exception unless it is a popular function in that case I would use as to keep it running fast. My opinion, critices and comments welcome nick I'm not an expert yet, but I play one at work. Yeah and here too.
Ista wrote: I guess would say the () is better in that it throws an exception unless it is a popular function in that case I would use as to keep it running fast. Umm, the last part of your sentence does not make any sense, care to elaborate? Casting using "as" will not allow your code to run faster than standard casting mechanisms between types, if standard casting fails it will throw a
InvalidCastException. If an "as" cast fails returning null and you access a method or property to your null object you will get aNullReferenceException. -Nick Parker -
Well I kind of like the as even though it resembles vb code. I'm used to type casting in c++ where I constantly check for null values but I would much rather throw an exception. But then again exceptions in .NET are very costly and therefore as would work better. But then again if your not using reflection you should know what the object was and it would be easier to test for null. I guess would say the () is better in that it throws an exception unless it is a popular function in that case I would use as to keep it running fast. My opinion, critices and comments welcome nick I'm not an expert yet, but I play one at work. Yeah and here too.
I use
aswhen its possible for some object to not be castable to the type I want. For example:private void MyEventHandler(object sender, EventArgs e)
{
ToolBarButton b = sender as Button;
MenuItem mi = sender as MenuItem;if( b != null )
{
// User clicked the toolbar button
}
else if( mi != null )
{
// User clicked the menu item or
// used the shortcut keys
}
}You would so something like this where the same event handler is used for two different events. In this case standard behavior dictates (at least it used to) that when you click the Print button on the toolbar you don't show the Print dialog box. While clicking the Print command in the menu you should display the Print dialog box. Unfortunately my example has one slight flaw, the way the ToolBar control works makes it hard to use my example. I still chose to use that example because it is something we should be familiar with. You should use a cast when you don't expect the cast to fail (an exceptional condition calls for an exception to be thrown). James "I despise the city and much prefer being where a traffic jam means a line-up at McDonald's" Me when telling a friend why I wouldn't want to live with him
-
Well I kind of like the as even though it resembles vb code. I'm used to type casting in c++ where I constantly check for null values but I would much rather throw an exception. But then again exceptions in .NET are very costly and therefore as would work better. But then again if your not using reflection you should know what the object was and it would be easier to test for null. I guess would say the () is better in that it throws an exception unless it is a popular function in that case I would use as to keep it running fast. My opinion, critices and comments welcome nick I'm not an expert yet, but I play one at work. Yeah and here too.
If the successful typecast is crucial in performing the function, go ahead and use
var = (type) object;. If, however, there are alternate ways of performing the function, theaskeyword is often better; even if you throw an exception anyway, because catching and rethrowing an exception is very expensive.void Function()
{
try
{
IReferenceService refSvc = (IReferenceService) GetService(typeof(IReferenceService));
// do something
}
catch (Exception exc)
{
throw new UsefulException(message, exc);
}
}void Function()
{
IReferenceService refSvc = GetService(typeof(IReferenceService)) as IReferenceService;
if (refSvc == null)
{
// alternatively, you could do it without refSvc
throw new UsefulException(message);
}
// do something
} -
There are somethings we are bound to miss, but I have a hard time beleiving, I missed this one. Did not pay attention to the usefulness of "AS"... Tanx! Rocky Moore <><
don't forget "IS" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vclrfispg.asp[^]
"When the only tool you have is a hammer, a sore thumb you will have."
-
Ista wrote: I guess would say the () is better in that it throws an exception unless it is a popular function in that case I would use as to keep it running fast. Umm, the last part of your sentence does not make any sense, care to elaborate? Casting using "as" will not allow your code to run faster than standard casting mechanisms between types, if standard casting fails it will throw a
InvalidCastException. If an "as" cast fails returning null and you access a method or property to your null object you will get aNullReferenceException. -Nick Parker -
I use
aswhen its possible for some object to not be castable to the type I want. For example:private void MyEventHandler(object sender, EventArgs e)
{
ToolBarButton b = sender as Button;
MenuItem mi = sender as MenuItem;if( b != null )
{
// User clicked the toolbar button
}
else if( mi != null )
{
// User clicked the menu item or
// used the shortcut keys
}
}You would so something like this where the same event handler is used for two different events. In this case standard behavior dictates (at least it used to) that when you click the Print button on the toolbar you don't show the Print dialog box. While clicking the Print command in the menu you should display the Print dialog box. Unfortunately my example has one slight flaw, the way the ToolBar control works makes it hard to use my example. I still chose to use that example because it is something we should be familiar with. You should use a cast when you don't expect the cast to fail (an exceptional condition calls for an exception to be thrown). James "I despise the city and much prefer being where a traffic jam means a line-up at McDonald's" Me when telling a friend why I wouldn't want to live with him
Okay so I am now totally confused Nick said if it cant cast to that type I get a cast exception. James says if it cant cast it just returns null. Well i guess I'll just test it myself, but in theory: C++: if cast to something thats not castable I get a null value(0), which is sweet then i just do an if an can ignore the horrible exception delay but if i cant I dont see what the difference is rather than code taste I'm not an expert yet, but I play one at work. Yeah and here too.
-
don't forget "IS" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vclrfispg.asp[^]
"When the only tool you have is a hammer, a sore thumb you will have."
-
Okay so I am now totally confused Nick said if it cant cast to that type I get a cast exception. James says if it cant cast it just returns null. Well i guess I'll just test it myself, but in theory: C++: if cast to something thats not castable I get a null value(0), which is sweet then i just do an if an can ignore the horrible exception delay but if i cant I dont see what the difference is rather than code taste I'm not an expert yet, but I play one at work. Yeah and here too.
Ista wrote: Nick said if it cant cast to that type I get a cast exception. James says if it cant cast it just returns null I think you are confusing the two methods of casting we are talking about here. If you do something like:
Object o = new Something();
Something s = (Something)o;and your cast fail, it will throw an
InvalidCastException(AssumingSomethingis derived fromObject). However if we are talking about an "as" casting and you doing something like:Object o = new Object();
Something s = o as Something();
if(s != null)
{
//... use s here.
}Failing to check if s is not equal to null and trying to access a member of s would throw an
NullReferenceExceptionif the cast for s was returned as null. -Nick Parker -
Ista wrote: Nick said if it cant cast to that type I get a cast exception. James says if it cant cast it just returns null I think you are confusing the two methods of casting we are talking about here. If you do something like:
Object o = new Something();
Something s = (Something)o;and your cast fail, it will throw an
InvalidCastException(AssumingSomethingis derived fromObject). However if we are talking about an "as" casting and you doing something like:Object o = new Object();
Something s = o as Something();
if(s != null)
{
//... use s here.
}Failing to check if s is not equal to null and trying to access a member of s would throw an
NullReferenceExceptionif the cast for s was returned as null. -Nick Parker -
Well I kind of like the as even though it resembles vb code. I'm used to type casting in c++ where I constantly check for null values but I would much rather throw an exception. But then again exceptions in .NET are very costly and therefore as would work better. But then again if your not using reflection you should know what the object was and it would be easier to test for null. I guess would say the () is better in that it throws an exception unless it is a popular function in that case I would use as to keep it running fast. My opinion, critices and comments welcome nick I'm not an expert yet, but I play one at work. Yeah and here too.
Ista wrote: But then again exceptions in .NET are very costly and therefore as would work better. How costly are exceptions in .NET and why? I can see how excessively coding around exceptions would not be smart... but at least in ordinary C++, exceptions aren't really expensive, as far as I know.
-
Ista wrote: But then again exceptions in .NET are very costly and therefore as would work better. How costly are exceptions in .NET and why? I can see how excessively coding around exceptions would not be smart... but at least in ordinary C++, exceptions aren't really expensive, as far as I know.
http://msdn.microsoft.com/vcsharp/using/understanding/perf/default.aspx?pull=/library/en-us/dndotnet/html/dotnetperftips.asp this is a link to one article. I spent 2 weeks going from link to link reading about how the CLR reacts and timing. This is a must read: http://msdn.microsoft.com/vcsharp/using/understanding/perf/default.aspx?pull=/library/en-us/dndotnet/html/fastmanagedcode.asp nick I'm not an expert yet, but I play one at work. Yeah and here too.