blocks|key|1069945|text|是的，捕获任何RuntimeException几乎总是一种代码味道。C2+Wiki似乎对此表示同意。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1069946|一个例外可能是一些特殊的防御性代码片段，它们运行来自其他模块的相当随机的代码。这种防御性结构的例子有EDT、线程池/执行器和插件系统。|1069947|entityMap|0|LINK|mutability|MUTABLE|url|http://c2.com/cgi/wiki?RuntimeException|1|http://en.wikipedia.org/wiki/Event_dispatching_thread^0|7|G|Y|7|0|0|1E|3|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@$9|Y|A|Z|1|10]]|E|$]]|$1|H|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]|P|$5|K|L|M|E|$N|Q]]]]

Yes, catching any <code>RuntimeException</code> is almost always a code smell. The <a href="http://c2.com/cgi/wiki?RuntimeException" rel="noreferrer">C2 Wiki</a> seems to agree.

An exception would probably be some specially defensive pieces of code which run pretty much random code from other modules. Examples for such defensive structures would be the <a href="http://en.wikipedia.org/wiki/Event_dispatching_thread" rel="noreferrer">EDT</a>, ThreadPools/Executors and plugin system.

blocks|key|1070093|text|我能想出一种用来感染NullPointerException的方法|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1070094|catch+(NullPointerException)+{
++++ApplyPainfulElectricShockToProgrammer();
}|code-block|syntax|javascript|1070095|entityMap^0|A|K|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|P|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|L|$]]

I can think of exactly one use for ever catching a <code>NullPointerException</code>:

<pre><code>catch (NullPointerException) {
 ApplyPainfulElectricShockToProgrammer();
}
</code></pre>

blocks|key|1284475|text|总的来说，我认为这是一种代码味道；在我看来，防御性检查更好。我会将其扩展到大多数未检查的异常，除了事件循环等希望捕获所有错误以进行报告/日志记录的异常。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1284476|我能想到的异常是对库的调用，它不能被修改，并且可能会生成一个空指针异常，以响应一些难以主动检查的断言失败。|1284477|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

In general, I think it is a code smell; it seems to me that defensive checks are better. I would extend that to cover most unchecked exceptions, except in event loops, etc. that want to catch all errors for reporting/logging.

The exception I can think of would be around a call to a library that can't be modified and which may generate a null pointer exception in response to some assertion failure that is difficult to proactively check.

blocks|key|1070377|text|有趣的|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1070378|我发现了一些不应该在工作中做的事情：|1070379|public+static+boolean+isValidDate(final+String+stringDateValue)+{
++++String+exp+=+"%5E[0-9]{2}/[0-9]{2}/[0-9]{4}$";
++++boolean+isValid+=+false;
++++try+{
++++++++if+(Pattern.matches(exp,+stringDateValue))+{
++++++++++++String[]+dateArray+=+stringDateValue.split("/");
++++++++++++if+(dateArray.length+==+3)+{
++++++++++++++++GregorianCalendar+gregorianCalendar+=+new+GregorianCalendar();
++++++++++++++++int+annee+=+new+Integer(dateArray[2]).intValue();
++++++++++++++++int+mois+=+new+Integer(dateArray[1]).intValue();
++++++++++++++++int+jour+=+new+Integer(dateArray[0]).intValue();

++++++++++++++++gregorianCalendar+=+new+GregorianCalendar(annee,+mois+-+1,
++++++++++++++++++++++++jour);
++++++++++++++++gregorianCalendar.setLenient(false);
++++++++++++++++gregorianCalendar.get(GregorianCalendar.YEAR);
++++++++++++++++gregorianCalendar.get(GregorianCalendar.MONTH);
++++++++++++++++gregorianCalendar.get(GregorianCalendar.DAY_OF_MONTH);
++++++++++++++++isValid+=+true;
++++++++++++}
++++++++}
++++}+catch+(Exception+e)+{
++++++++isValid+=+false;
++++}
++++return+isValid;
}|code-block|syntax|javascript|1070380|baaad+:)|1070381|开发人员想让日历抛出这种异常：|1070382|java.lang.IllegalArgumentException:+DAY_OF_MONTH
++++at+java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2316)
++++at+java.util.Calendar.updateTime(Calendar.java:2260)
++++at+java.util.Calendar.complete(Calendar.java:1305)
++++at+java.util.Calendar.get(Calendar.java:1088)|1070383|要使这些值无效...|1070384|是的，它是有效的，但这不是一个很好的实践……|1070385|引发异常(特别是填充堆栈跟踪)的成本比手动检查数据而没有异常要多得多……|1070386|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|11|8|@]|9|@]|A|$G|H]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

Funny

I just found something that shouldn't be done at work:

<pre><code>public static boolean isValidDate(final String stringDateValue) {
 String exp = "^[0-9]{2}/[0-9]{2}/[0-9]{4}$";
 boolean isValid = false;
 try {
 if (Pattern.matches(exp, stringDateValue)) {
 String[] dateArray = stringDateValue.split("/");
 if (dateArray.length == 3) {
 GregorianCalendar gregorianCalendar = new GregorianCalendar();
 int annee = new Integer(dateArray[2]).intValue();
 int mois = new Integer(dateArray[1]).intValue();
 int jour = new Integer(dateArray[0]).intValue();

 gregorianCalendar = new GregorianCalendar(annee, mois - 1,
 jour);
 gregorianCalendar.setLenient(false);
 gregorianCalendar.get(GregorianCalendar.YEAR);
 gregorianCalendar.get(GregorianCalendar.MONTH);
 gregorianCalendar.get(GregorianCalendar.DAY_OF_MONTH);
 isValid = true;
 }
 }
 } catch (Exception e) {
 isValid = false;
 }
 return isValid;
}
</code></pre>

baaad :)

The developper wanted the calendar to raise exceptions of this kind:

<pre><code>java.lang.IllegalArgumentException: DAY_OF_MONTH
 at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2316)
 at java.util.Calendar.updateTime(Calendar.java:2260)
 at java.util.Calendar.complete(Calendar.java:1305)
 at java.util.Calendar.get(Calendar.java:1088)
</code></pre>

to invalidate the values...

Yes it works but it's not a really good practice...

Raising exception (particularly filling the stack trace) cost a lot more than just checking data manually without an exception...

blocks|key|1070438|text|这很糟糕，但它可以生成优化的字节码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1070439|如果整型i在大多数情况下不是null，那么选中会降低整体性能。检查本身需要3条指令(0-4)。然后，整个案例需要7条指令(0-14)。|offset|length|style|CODE|1070440|public+class+IfNotNull+{

++++public+Integer+i;

++++public+String+getIAsString()+{
++++++++if+(i+!=+null)+{
++++++++++++return+i.toString();
++++++++}+else+{
++++++++++++return+"";
++++++++}
++++}
}

++public+java.lang.String+getIAsString();
++++Code:
+++++++0:+aload_0+++++++
+++++++1:+getfield++++++#2++++++++++++++++++//+Field+i:Ljava/lang/Integer;
+++++++4:+ifnull++++++++15
+++++++7:+aload_0+++++++
+++++++8:+getfield++++++#2++++++++++++++++++//+Field+i:Ljava/lang/Integer;
++++++11:+invokevirtual+#3++++++++++++++++++//+Method+java/lang/Integer.toString:()Ljava/lang/String;
++++++14:+areturn+++++++//+<-+here+we+go
++++++15:+ldc+++++++++++#4++++++++++++++++++//+String+
++++++17:+areturn+|code-block|syntax|javascript|1070441|遵循Python世界中常见的EAFP方法。null的情况将是昂贵的，但我们只需要4个指令(0-7)的not+null情况。|1070442|public+class+TryCatch+{

++++public+Integer+i;

++++public+String+getIAsString()+{
++++++++try+{
++++++++++++return+i.toString();
++++++++}+catch+(NullPointerException+npe)+{
++++++++++++return+"";
++++++++}
++++}
}

++public+java.lang.String+getIAsString();
++++Code:
+++++++0:+aload_0+++++++
+++++++1:+getfield++++++#2++++++++++++++++++//+Field+i:Ljava/lang/Integer;
+++++++4:+invokevirtual+#3++++++++++++++++++//+Method+java/lang/Integer.toString:()Ljava/lang/String;
+++++++7:+areturn+++++++//+<-+here+we+go
+++++++8:+astore_1++++++
+++++++9:+ldc+++++++++++#5++++++++++++++++++//+String+a
++++++11:+areturn+++++++
++++Exception+table:
+++++++from++++to++target+type
+++++++++++0+++++7+++++8+++Class+java/lang/NullPointerException|1070443|谁知道，如果JIT编译器可以优化这一点呢？|1070444|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.python.org/2/glossary.html#term-eafp^0|0|4|1|E|4|0|0|L|4|1E|8|E|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@$D|12|E|13|F|G]|$D|14|E|15|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|16|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|17|8|@$D|18|E|19|F|G]|$D|1A|E|1B|F|G]]|9|@$D|1C|E|1D|1|1E]]|A|$]]|$1|O|3|P|5|J|7|1F|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|1G|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

It is bad, but it could produce optimized bytecode.

If Integer <code>i</code> is not <code>null</code> most of the time, then check decreases overall performance. The check itself costs 3 instructions (0-4). The whole case then takes 7 instructions (0-14).

<pre><code>public class IfNotNull {

 public Integer i;

 public String getIAsString() {
 if (i != null) {
 return i.toString();
 } else {
 return "";
 }
 }
}

 public java.lang.String getIAsString();
 Code:
 0: aload_0 
 1: getfield #2 // Field i:Ljava/lang/Integer;
 4: ifnull 15
 7: aload_0 
 8: getfield #2 // Field i:Ljava/lang/Integer;
 11: invokevirtual #3 // Method java/lang/Integer.toString:()Ljava/lang/String;
 14: areturn // &lt;- here we go
 15: ldc #4 // String 
 17: areturn 
</code></pre>

Following <a href="http://docs.python.org/2/glossary.html#term-eafp" rel="nofollow">EAFP</a> approach which is common in Python world. The <code>null</code> case will be costly, but we need only 4 instructions (0-7) for <code>not null</code> case. 

<pre><code>public class TryCatch {

 public Integer i;

 public String getIAsString() {
 try {
 return i.toString();
 } catch (NullPointerException npe) {
 return "";
 }
 }
}

 public java.lang.String getIAsString();
 Code:
 0: aload_0 
 1: getfield #2 // Field i:Ljava/lang/Integer;
 4: invokevirtual #3 // Method java/lang/Integer.toString:()Ljava/lang/String;
 7: areturn // &lt;- here we go
 8: astore_1 
 9: ldc #5 // String a
 11: areturn 
 Exception table:
 from to target type
 0 7 8 Class java/lang/NullPointerException
</code></pre>

Who knows, if JIT compiler can optimize this?

blocks|key|1284557|text|当然是这样。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1284558|大多数情况下，你的变量一开始就不应该是空的。许多新语言都内置了对不可为空的引用类型的支持--即保证永远不为空的类型。|1284559|对于允许传入的值为空的情况，您需要进行检查。但是异常绝对是一种不好的方法。|1284560|一条if语句可能需要三条指令才能执行，并且是一个本地检查(这意味着，您在需要保证的地方进行检查)。|1284561|另一方面，使用异常可能需要更多的指令--系统试图查找该方法，但失败了，在异常表中查找适当的异常处理程序，跳转到那里，执行处理程序，然后再次跳转。此外，检查可能是非本地的。如果你的代码是这样的：|1284562|try
++return+contacts.find("Mom").getEmail()
catch+(NullPointerException+e)
++return+null|code-block|syntax|javascript|1284563|您不知道NPE是在“getEmail”中还是在“find”中抛出的。|1284564|以一种更模糊的方式编写的非常，非常常见的模式的技术上更糟糕的解决方案？它不是等级，但它肯定闻起来很难闻:/|1284565|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|Z|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

It certainly is.

Most of the time, your variables shouldn't be null to begin with. Many new languages are coming out with builtin support for non-nullable reference types -- that is, types which are guaranteed to never be null.

For the times when your incoming value is allowed to be null, you need to do a check. But exceptions are definitively a bad way to do this. 

An if statement takes perhaps three instructions to perform and is a local check (meaning, you make the check in the same place as you need the guarantee). 

Using an exception, on the other hand, may take many more instructions -- the system attempts to look up the method, fails, looks through the exception table for the appropriate exception handler, jumps there, executes the handler, and jumps again. Furthermore, the check is potentially non-local. If your code is something like this: 

<pre><code>try
 return contacts.find("Mom").getEmail()
catch (NullPointerException e)
 return null
</code></pre>

You don't know whether the NPE was thrown in 'getEmail' or in 'find'. 

A technical worse solution to a very, very common pattern written in a more obfuscated way? It isn't rank, but it definitely smells bad :/

blocks|key|1070052|text|唯一应该捕获NullPointerException+(或者明确地说，是任何Throwable)的地方是在某个顶层或系统边界，这样你的程序就不会完全崩溃，可以恢复。例如，在web.xml中设置错误页提供了一个通用的方法，这样web应用程序就可以从异常中恢复并通知用户。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1070053|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The only place you should catch a NullPointerException (or specifically, just any Throwable) is at some top-level or system boundary so that your program doesn't completely crash and can recover. For example, setting up an error page in your web.xml provides a catch-all so that a web application can recover from an exception and notify the user.

blocks|key|1070160|text|很久以前，我只有一个用途。一个特别愚蠢的库会在通过键请求集合中的对象时抛出NullPointerException，但没有找到该对象。除了通过键查找之外，没有其他方法可以查找，也没有办法检查对象是否存在。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1070161|一段时间后，我们启动了供应商并开始修改库。现在，这个库抛出了一个更好的异常(我的更改)，并且有一个检查函数(别人的更改)。|1070162|当然，我总是在try块中只有一行结束。再多的话，我自己也会为糟糕的代码感到内疚。|1070163|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Long ago I had one use. A particularly stupid library would throw NullPointerException when asked for an object in a collection by key and the object was not found. There was no other way to look up than by key and no way to check if the object existed.

Some time later we booted the vendor and started modifying the library. Now the library throws a better exception (my change) and has a check function (somebody else's change).

Of course I'd always end up with exactly one line inside the try block. Any more and I myself would be guilty of bad code.

blocks|key|1284867|text|捕获空指针异常实际上取决于上下文...一个人应该努力避免严格的绝对规则。规则应该在上下文中应用-希望捕获此异常，并将整个软件置于某种稳定状态-什么都不做或几乎什么都不做。所有这样的编码规则都应该被很好地理解|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1284868|此时，您可以查看您的软件审计跟踪...您应该这样做，并发现此异常的根源。|1284869|空指针异常永远不会发生的想法必须是可验证的。首先做一个静态分析...(如果第三方代码/组件出现，这将更加困难)，然后使用相关工具进行详尽的状态空间搜索。|1284870|X|1284871|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Catching a NULL pointer exception really depends on the context ... one should strive to avoid strict absolute rules ... rules should be applied in context - want to trap this exception and put the entire software in some STABLE state - doing nothing or almost next to nothing. All such coding rules should be well understood 

At this point you then look at your software AUDIT TRACE ... which you should be doing and discover the SOURCE of this exception.

The idea that a NULL Pointer Exception Shall Never Occur must be verifiable. First do a static analysis ... (which is harder if 3rd party code/components come in) and then do an exhaustive state space search using relevant tools.

x

blocks|key|1284916|text|捕获NPE(实际上是任何RTE)对于干净地终止基于Swing-GUI的应用程序是必要的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1284917|编辑:在这种情况下，它通常是通过UncaughtExceptionHandler完成的。|1284918|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Catching NPEs (any RTEs in fact) can be necessary to cleanly terminate a Swing-GUI based application. 

edit : in this case, it is usually done via a UncaughtExceptionHandler though.

blocks|key|1070018|text|我试图保证我的接口的结果，但如果一些库或某人的代码可以生成null作为结果，我希望有一个保证捕获它可能是可行的。当然，一旦你抓住它，你会做什么是你自己的事。有时候检查null是没有意义的，如果你捕捉到了它，你就有了其他的方法来解决这个问题，虽然可能不是很好，但是可以完成工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1070019|我的意思是尽可能使用异常，这是一个很好的语言特性。|1070020|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I try to guarantee results from my interfaces, but if some library or someones code can produce null as a result and im expecting a guarantee catching it might be viable. Ofcourse what you do once you catch it is up to you. Sometimes it just doesnt make sense to check for null, and if you catch it you have some other method of solving the problem that might not be as good but gets the job done.

What im saying is use exceptions for what you can, its a pretty good language feature.

blocks|key|1070065|text|如果您的方法调用外部接口(或SOAP+API)，并且返回值可能为空，则捕获NullPointerException会很有用。除此之外，捕获这些异常并没有什么大的好处。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1070066|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Catching a NullPointerException can be useful if your method calls an external interface (or a SOAP API) and there is a possibility that the value returned might be Null. Other than that, there is not a huge benefit to catching these exceptions.

blocks|key|1070205|text|是的，在Java中，需要检查NullPointerException。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1070206|当应用程序试图在需要对象的情况下使用null时抛出。其中包括：|1070207|调用null对象的实例方法。访问或修改空对象的字段。将null的长度视为一个数组。访问或修改null的插槽，就像它是一个数组一样。抛出null，就像它是Throwable值一样。|1070208|应用程序应该抛出此类的实例，以指示null对象的其他非法使用。|1070209|当读取文本文件(即XML)时，其记录未被验证为正确的NullPointerException字符和记录格式。|1070210|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Yes in Java there is a need to check for a NullPointerException.

Thrown when an application attempts to use null in a case where an object is required. These include: 

Calling the instance method of a null object. 
Accessing or modifying the field of a null object. 
Taking the length of null as if it were an array. 
Accessing or modifying the slots of null as if it were an array. 
Throwing null as if it were a Throwable value. 

Applications should throw instances of this class to indicate other illegal uses of the null object. 

NullPointerException in other languages when reading text files (i.e. XML), whose records have not been validated to the correct ASCII character and record format.

blocks|key|1070489|text|如果程序员是初学者，他可能有一种习惯，那就是捕捉每一个阻止他获得最终输出的异常。这不应该被代码审查者接受。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1070490|捕获任何RuntimeException都是不好的。但如果真的有必要，那么代码中的注释将对将来处理该代码的程序员非常有帮助。如果你不能写一个合理的评论来捕捉它们，那么你就必须避免它们。句号。|1070491|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If the programmer is beginner he may have a habit to catch every exception which stops him to get the final output. This should not be entertained by code reviewers.

Catching any RuntimeException is bad. But if it is really necessary then a comment in code will be really helpful for future programmers who will work on that code. If you cannot write a reasonable comment for catching them then you must avoid them. period.

Recently a co-worker of mine wrote in some code to catch a null pointer exception around an entire method, and return a single result. I pointed out how there could've been any number of reasons for the null pointer, so we changed it to a defensive check for the one result.

However, catching NullPointerException just seemed wrong to me. In my mind, Null pointer exceptions are the result of bad code and not to be an expected exception in the system.

Are there any cases where it makes sense to catch a null pointer exception?

Is Catching a Null Pointer Exception a Code Smell?

最近，我的一个同事写了一些代码来捕获整个方法周围的空指针异常，并返回单个结果。我指出了空指针可能有许多原因，所以我们将其更改为针对一个结果的防御性检查。然而，在我看来，捕获NullPointerException似乎是错误的。在我看来，空指针异常是错误代码的结果，而不是系统中预期的异常。是否存在捕获空指针异常有意义的情况？

问捕获Null指针异常是一种代码气味吗？
EN

回答 14

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问捕获Null指针异常是一种代码气味吗？EN

回答 14

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问捕获Null指针异常是一种代码气味吗？
EN