是否有令人信服的理由反对使用 C# 关键字“as”？

发布于 2024-07-13 18:31:14 字数 292 浏览 10 评论 0原文

我发现使用以下内容：

TreeViewItem i = sender as TreeViewItem;
if(i != null){ ... }

比使用以下内容更容易编写和理解：

if(sender.GetType() == typeof(TreeViewItem)){
    TreeViewItem i = (TreeViewItem)sender;
    ...
}

是否有令人信服的理由不使用第一个构造？

原文

I find that using the following:

TreeViewItem i = sender as TreeViewItem;
if(i != null){ ... }

is easier to write and understand than:

if(sender.GetType() == typeof(TreeViewItem)){
    TreeViewItem i = (TreeViewItem)sender;
    ...
}

Are there compelling reasons not to use the first construct?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

杯别 2024-07-20 18:31:15

不，我经常使用它。它允许您以干净的方式避免 InvalidCastException 。

例如：

TreeViewItem tvItem = sender as TreeViewItem;

if (tvItem != null) return;

// Do stuff

相对于：

try
{
    TreeViewItem tvItem = (TreeViewItem)sender;
    // Do stuff.
}
catch (InvalidCastException ex)
{
    // Didn't work, do something about it
    return; // ... or not...
}

No, I use it quite a bit. It allows you to avoid InvalidCastExceptions in a clean way.

For example:

TreeViewItem tvItem = sender as TreeViewItem;

if (tvItem != null) return;

// Do stuff

as opposed to:

try
{
    TreeViewItem tvItem = (TreeViewItem)sender;
    // Do stuff.
}
catch (InvalidCastException ex)
{
    // Didn't work, do something about it
    return; // ... or not...
}

回复收藏 0 原文

夜巴黎 2024-07-20 18:31:15

“as”更快，但要记住的是：

“as”返回 null 而不是抛出异常（如果这是一个问题）
它不会执行自定义转换iirc
它不适用于参考->值

编辑：“as”肯定更快（http://www.codeproject. com/KB/cs/csharpcasts.aspx）

Edit2：所以基本上是速度与安全的决定

回复收藏 0 原文

哥，最终变帅啦 2024-07-20 18:31:15

如果获取错误的类型会是一个错误，那么您应该使用强制转换。原因是确实有问题，你应该知道它。

如果该值有可能为空，并且发生这种情况时这不是系统中的错误，则使用“as”。原因是只要可以接受空值返回，就应该使用“as”。

请记住，您不能使用“as”转换为值类型，因为它们不接受空值。如果您有值类型并想要使用“as”，则需要使用可为空的值类型。

何时使用“as”与铸造

回复收藏 0 原文

舞袖。长 2024-07-20 18:31:14

在大多数情况下，我更喜欢强制转换而不是 as ，因为通常如果对象的类型错误，则表明存在错误。 Bug应该会导致异常（IMO） - 并且执行转换的那一行的 InvalidCastException 比代码后面的 NullReferenceException 清楚得多。

当传递对您不想要的类型的对象的引用有效且合法时，应使用 as。这种情况确实会出现，但根据我的经验，不像正常选角那么频繁。

然而，使用 GetType() 比较类型很少是正确的解决方案 - 仅当您想要检查所涉及的精确类型而不是兼容类型时，它才适用。

我写了一个明显更长的答案关于其他地方的“演员与扮演”讨论。

回复收藏 0 原文

顾忌 2024-07-20 18:31:14

完全不是——它让您有机会验证转换（转换）是否完成正常。如果这样做，

TreeViewItem i = (TreeViewItem) sender;

如果转换失败，您可能会遇到异常。

Not at all - it gives you the chance to verify that the conversion (cast) was done OK. If you do

TreeViewItem i = (TreeViewItem) sender;

you might get an exception if the cast fails.

回复收藏 0 原文

全部不再 2024-07-20 18:31:14

一般来说，这两个片段不是等价的。即使 sender 是 TreeViewItem 的孙子，TreeViewItem i = sender as TreeViewItem 也会产生正确的结果，而 sender .GetType() == typeof(TreeViewItem) 将为 true 仅当 sender 恰好为 TreeViewItem 时> 及其任何可能的子类。

回复收藏 0 原文

幽梦紫曦～ 2024-07-20 18:31:14

“如”：好东西。一直使用它。

如果您确实想要手动比较类型的替代方法，请尝试：

  if(person is Employee) { }

读起来更好。

"as": good stuff. use it all the time.

if you really want an alternative to manually comparing types try:

  if(person is Employee) { }

reads better yet.

回复收藏 0 原文

飘逸的'云 2024-07-20 18:31:14

您的示例最好写为：

if (sender is TreeViewItem) {
    TreeViewItem i = (TreeViewItem)sender;
    ...
}

as 运算符可以帮助避免这种双重类型检查。所以对于你引用的例子，我想说这绝对是一个很好的解决方案。

然而，在某些情况下，您确实确实想要演员阵容。如果您需要一个 TreeViewItem 并且不需要其他任何东西，那么转换将确保在您获得其他任何东西时抛出 InvalidCastException 。

就像在大多数情况下一样，这里没有一揽子规则：使用正确的工具完成正确的工作。

Your example would be better written as:

if (sender is TreeViewItem) {
    TreeViewItem i = (TreeViewItem)sender;
    ...
}

It is exactly this dual type checking that the as operator can help avoid. So for your cited example, I would say it is definitely a good solution.

However, there are situations where you really do want a cast. If you're expecting a TreeViewItem and want nothing else, casting will ensure an InvalidCastException is thrown if you're given anything else.

Just like in most situations, there is no blanket rule here: use the right tool for the right job.

回复收藏 0 原文