471,321 Members | 1,810 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,321 software developers and data experts.

Casting using "as" question

What is the benefit of using "as" vs the other?

HttpWebRequest myReq
= (HttpWebRequest)WebRequest.Create("http://www.contoso.com/");

vs.

HttpWebRequest myReq = WebRequest.Create("http://www.contoso.com/") as
HttpWebRequest;

Based on the MS documenation "The as operator is like a cast except that it
yields null on conversion failure instead of raising an exception. "

I've read some internal coding standards that state "Use the as operator to
defensively cast to a type", but I don't quite get the benefit of this and
want an outside opinion.

Thanks.

Jan 20 '06 #1
5 1863
It returns an object of the resulting cast (if successful) or null. So you
can use the object afterwards and it doesn't raise an exception (just like
the MS documentation states).

Best regards,
--
Angel J. Hernández M.
MCP - MCAD - MCSD - MCDBA
Microsoft MVP ASP/ASP.NET
http://groups.msn.com/desarrolladoresmiranda
http://www.consein.com

"Dave" <Da**@discussions.microsoft.com> wrote in message
news:F6**********************************@microsof t.com...
What is the benefit of using "as" vs the other?

HttpWebRequest myReq
= (HttpWebRequest)WebRequest.Create("http://www.contoso.com/");

vs.

HttpWebRequest myReq = WebRequest.Create("http://www.contoso.com/") as
HttpWebRequest;

Based on the MS documenation "The as operator is like a cast except that
it
yields null on conversion failure instead of raising an exception. "

I've read some internal coding standards that state "Use the as operator
to
defensively cast to a type", but I don't quite get the benefit of this and
want an outside opinion.

Thanks.

Jan 20 '06 #2
Using "as" allows for the "graceful" failure of casting one object to
another.
As per your examples:
HttpWebRequest myReq
= (HttpWebRequest)WebRequest.Create("http://www.contoso.com/"); --This
will cause an exception of InvalidCastException if the system can cast the
web request as a httpwebrequest. But if we were to use "as"

vs.

HttpWebRequest myReq = WebRequest.Create("http://www.contoso.com/") as
HttpWebRequest; -- this will capture the possible exception and return a
null allowing for your code to be execute as normal.
Think of "as" as being
public static void as(ref object a, object b, Type someType){
try{
a = (someType)b;
}catch{ a = null;}
}
}
In some cases using "as" is much safer than attempting to forceably cast one
type to another type.

Thaddaeus

"Dave" <Da**@discussions.microsoft.com> wrote in message
news:F6**********************************@microsof t.com... What is the benefit of using "as" vs the other?

HttpWebRequest myReq
= (HttpWebRequest)WebRequest.Create("http://www.contoso.com/");

vs.

HttpWebRequest myReq = WebRequest.Create("http://www.contoso.com/") as
HttpWebRequest;

Based on the MS documenation "The as operator is like a cast except that
it
yields null on conversion failure instead of raising an exception. "

I've read some internal coding standards that state "Use the as operator
to
defensively cast to a type", but I don't quite get the benefit of this and
want an outside opinion.

Thanks.

Jan 20 '06 #3
> What is the benefit of using "as" vs the other?

HttpWebRequest myReq
= (HttpWebRequest)WebRequest.Create("http://www.contoso.com/");

vs.

HttpWebRequest myReq = WebRequest.Create("http://www.contoso.com/") as
HttpWebRequest;

Based on the MS documenation "The as operator is like a cast except that it
yields null on conversion failure instead of raising an exception. "

I've read some internal coding standards that state "Use the as operator to
defensively cast to a type", but I don't quite get the benefit of this and
want an outside opinion.

Thanks.


And an extra remark:

unlike a direct cast, you can't use "as" on value types
("theobj as int"), because it can return null, which value-types can't
handle.

Hans Kesting
Jan 20 '06 #4
Hans Kesting wrote:
And an extra remark:

unlike a direct cast, you can't use "as" on value types
("theobj as int"), because it can return null, which value-types can't
handle.


That's not strictly true under .NET 2.0. Nullable<T> types are still
value types, but can be used with "as":

using System;

class Test
{
static void Main()
{
object o = 5;
int? x = o as int?;
}
}

(Note that if you remove the last ? in the program, you'll get a
compiler error CS0077 which has an inaccurate description - I've
reported it to MS).

Jon

Jan 20 '06 #5
Internally, they are two different CIL instructions -- castclass
(straight cast) and isinst (as.) The primary difference, as noted
already is that the castclass instruction generates an exception when no
cast exists while the isinst just places a null value on the evaluation
stack.

The implication is that if you know -- or expect your type to always be
castable then the castclass instruction provides some runtime safety in
case an unexpected value comes through -- and you dont suffer the
penalty of spinning up an exception. If, on the other hand, you are not
sure what the type will be, and you want to handle it gracefully, then
isinst allows you to avoid the performance penalties of an exception if
the class cannot be cast.

Dave wrote:
What is the benefit of using "as" vs the other?

HttpWebRequest myReq
= (HttpWebRequest)WebRequest.Create("http://www.contoso.com/");

vs.

HttpWebRequest myReq = WebRequest.Create("http://www.contoso.com/") as
HttpWebRequest;

Based on the MS documenation "The as operator is like a cast except that it
yields null on conversion failure instead of raising an exception. "

I've read some internal coding standards that state "Use the as operator to
defensively cast to a type", but I don't quite get the benefit of this and
want an outside opinion.

Thanks.

Jan 20 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

15 posts views Thread by Bobby C. Jones | last post: by
10 posts views Thread by Max André Bündchen | last post: by
5 posts views Thread by Hayato Iriumi | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.