什么时候处理一个空指针/引用异常优先做空检查？ [英] When is handling a null pointer/reference exception preferred over doing a null check?

问题描述

我有一个奇怪的问题，我一直在想，但永远看不到实际的用途。我正在寻找是否有足够的理由来解决这个问题。

何时处理空指针/引用异常优先做空检查？

这适用于必须处理具有异常处理功能的空指针/引用的任何语言。

我对此的通常响应是在使用指针/引用执行任何操作之前执行空检查。如果非空，继续像正常一样使用它。如果为空，请处理该错误或提高该错误。

即（在C＃中）

  string str = null; 
 if（str == null）
 {
 //错误！ 
} 
 else 
 {
 // do stuff 
 int length = str.Length; 
 // ... 
} 
  

但是，如果我们不做支票只是盲目使用它，一个例外会被提升。

  string str = null; 
 int length = str.Length; // oops，NullReferenceException 
 // ... 
  

作为一个例外，我们当然可以抓住它，所以没有什么是阻止我们这样做（或在吗？）：

  string str = null; 
 try 
 {
 int length = str.Length; // oops，NullReferenceException 
 // ... 
} 
 catch（NullReferenceException ex）
 {
 //但是没关系，我们现在可以处理
} 
  

现在我承认，这不是最干净的代码，但它的工作代码也不少，不会正常这样做。但是有没有设计模式或这样做有用的东西？可能比直接执行更有用，请事先进行空检查。

我可以想象的唯一的情况可能是有用的是在一个多线程环境中，一个无保护的共享变量设置为null太早。但是多久会发生这种情况？保护变量的良好代码不会有这个问题。或者如果有人正在编写一个调试器，并希望将这个异常显式抛出，只能包装它或者什么。可能是一个看不见的性能优势，或者不需要代码中的其他东西？

我可能已经回答了我的一些问题，但还有其他用途吗？我不是在寻找，这样做只是因为我们可以的例子，或者只是编写不好的代码，但它的实际用途。虽然我没关系，没有实际用途，做支票。

解决方案

问题是所有空指针异常都相似。任何可以添加的会计，以指示哪个名称跳过异常不能比首先检查null更有效。

I have an odd question that I have always thought about, but could never see a practical use for. I'm looking to see if there would be enough justification for this.

When is handling a null pointer/reference exception preferred over doing a null check? If at all.

This applies to any language that has to deal with null pointers/references which has exception handling features.

My usual response to this would be to perform a null check before doing anything with the pointer/reference. If non-null, continue like normal and use it. If null, handle the error or raise it.

i.e., (in C#)

string str = null;
if (str == null)
{
    // error!
}
else
{
    // do stuff
    int length = str.Length;
    // ...
}

However if we were not to do the check and just blindly use it, an exception would be raised.

string str = null;
int length = str.Length; // oops, NullReferenceException
// ...

Being an exception, we could certainly catch it so nothing is stopping us from doing this (or is there?):

string str = null;
try
{
    int length = str.Length; // oops, NullReferenceException
    // ...
}
catch (NullReferenceException ex)
{
    // but that's ok, we can handle it now
}

Now I admit, it's not the cleanest code, but it's no less working code and I wouldn't do this normally. But is there a design pattern or something where doing this is useful? Perhaps more useful than doing the straight up, null check beforehand.

The only cases where I can imagine this might be useful is in a multi-threaded environment where an unprotected shared variable gets set to null too soon. But how often does that happen? Good code that protects the variables wouldn't have that problem. Or possibly if one was writing a debugger and wanted the exception to be thrown explicitly only to wrap it or whatnot. Maybe an unseen performance benefit or removes the need for other things in the code?

I might have answered some of my questions there but is there any other use to doing this? I'm not looking for, "do this just because we can" kinds of examples or just poorly written code, but practical uses for it. Though I'll be ok with, "there's no practical use for it, do the check."

解决方案

The problem is that all null pointer exceptions look alike. Any accounting that could be added to indicate which name tripped the exception can't be any more efficient than just checking for null in the first place.

这篇关于什么时候处理一个空指针/引用异常优先做空检查？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！