如果你正在做一些微不足道的事情,如果成功获得奖金但可能失败并且你不想使用try / catch来支付管理费用,那么as
关键字和测试null是否可以语义替换尝试/赶上?
var item = new CreateItem(filename) as Item;
if (item != null) {
ItemList.Add(item);
}
答案 0 :(得分:3)
这取决于你想要捕获的错误。我会考虑使用与int.TryParse
等相同的模式 - 在这种情况下,我不会使用as
,个人:
Item item;
if (TryCreateItem(filename, out item))
{
// Use it
}
else
{
// Don't
}
或者你可以让TryCreateItem
如果失败则返回null:
Item item = TryCreateItem();
if (item != null)
{
}
as
实际上用于评估表达式的执行时间类型属于所需类型但可能不同的情况类型。
答案 1 :(得分:2)
不是这种情况,不是。构造函数将成功,并且您将成功创建CreateItem
,否则如果出现错误将抛出异常,您将不得不在try / catch块中处理它。
如果您确实不想使用例外,请创建Initialize
方法:
CreateItem item = new CreateItem(filename); // this throws no exceptions
bool initialized = item.Initialize(); // this returns true if intialize succeeded, false if something went wrong
if (initialized) {
// stuff
}
答案 2 :(得分:1)
如果您的构造函数不能抛出任何其他异常,那么是。
答案 3 :(得分:1)
try
在.NET中非常有效(如果实际上抛出异常并且catch
块发挥作用,它会产生更多开销),所以你不必担心关于try
块太多了。
此外,as
关键字只有在投射失败时才会通过返回null
来避免异常。如果CreateItem
抛出异常,您仍然需要处理它。因此,在您的情况下,as
关键字并不能真正取代try / catch
as
关键字不替换异常处理。它只适用于可能失败的铸造。
答案 4 :(得分:0)
对于cast上的空指针异常的特定问题,确定它可以。但是如果CreateItem抛出异常,你的应用程序将会死于过早死亡。
答案 5 :(得分:0)
我认为这不是一个好主意。 as
关键字具有不同的含义,虽然它是进行显式转换和捕获异常的一个很好的替代方法,但它不是一个好的通用流控制机制。
不要使用as
,只需让您的方法返回null并检查它。你不需要伪造它。
答案 6 :(得分:0)
如果允许转换失败,您可以使用as
关键字。否则,您需要使用(Item)new CreateItem(filename)
。
因此,您可以使用as / null检查替换try / catch,但请记住,除NullReferenceException
之外还有更多类型的异常。也许你还想抓住其他异常类型。
答案 7 :(得分:0)
如果您的块在CreateItem未返回Item实例的情况下用于捕获InvalidCastException,则可以将其替换为“as”代码以用于相同目的。
如果您的块用于捕获其他异常,则答案为否。