blocks|key|4019224|text|如果您可以防止异常，那么最好是这样做。例如，任何NullPointerException通常指示编程错误。(这也是它是RuntimeException的原因之一。)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4019225|当您希望能够检测到某一代码层中的失败情况时，异常更有用，但您不希望在那里处理失败情况，而是在更高级别的代码中进行处理。也就是说，您打算在堆栈中抛出不止一个帧的异常--或者抛出堆栈中的所有帧。当您不希望程序能够有意义地处理问题时，异常也很有用。|4019226|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 you can prevent exceptions, then it's better programming practice to do so. For example, any NullPointerException usually indicates a programming error, IMO. (Which is one reason it's a RuntimeException.)

Exceptions are more useful when you expect to be able to detect a failure condition in one layer of code, but you don't want to handle the failure condition there but instead at a somewhat higher level of code. That is, you intend to throw the Exception more than one frame up the stack -- or all of the way up the stack. Exceptions are also useful when you do not expect the program to be able to meaningfully handle the problem.

blocks|key|4864237|text|避免那些你能做到的(NullPointerExceptions、NullReferenceExceptions等)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4864238|捕获更难捕获的那些(Sql+Errors...where，它们可能不在您的控制范围之内，但您需要在它们之后优雅地进行清理)。|4864239|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|$]]

Avoid the ones you can (NullPointerExceptions, NullReferenceExceptions, etc.).

Catch the ones that are a little trickier to catch (Sql Errors...where they may be out of your control but you need to gracefully clean up after them).

blocks|key|1262877|text|通常，如果这样做是合理的，您应该首先尝试防止异常发生。通常，这并不合理，或者可能是完全不可能的(特别是当涉及到io时)，但这就是try/catch的用途。特别是，这意味着您应该始终检查指针和数组索引，以防止NullPointerException和ArrayIndexOutOfBoundsException。当然，除非你对它无能为力，不得不重新抛出它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1262878|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|$]]

In general, if it is reasonable to do so, you should try to prevent the exception from occurring in the first place. Quite frequently, it's not reasonable or possibly flat-out impossible (especially when io in concerned), but that's what try/catch are for. In particular, this means that you should always check your pointers and your array indexes to prevent the NullPointerException and ArrayIndexOutOfBoundsException. Unless, of course, there is nothing you can do about it and would have to rethrow it anyway.

blocks|key|4019359|text|在我看来，只有当引用为null+(再次，例如)实际上表示有效的程序状态时，才有必要防止NullPointerException+(例如)。如果没有，你应该阻止它的发生，因为在这种情况下，你程序很难死。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|4019360|特别是在Java语言中，从RuntimeException派生的某些异常(比如IllegalArgumentException)实际上是用来通知编程错误的，如果您的程序是正确的，这些情况就不应该发生。我试着遵循这一点。如果我正在编写一个对其参数进行限制的方法，我将不会试图避免抛出异常。我会积极地抛出一个。|4019361|entityMap^0|S|7|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

In my opinion, it only makes sense to prevent a NullPointerException (for example) when a reference being null (again, for example) actually represents a valid program state. If it does not, you should not prevent it from happening, because in that case you want the program to die hard.

In Java in particular, certain exceptions descending from RuntimeException (such as IllegalArgumentException) are really meant to signal programming errors, conditions that should not happen if your program is correct. I try to follow this. If I am writing a method that places restrictions on its arguments, I will not try to avoid throwing an exception. I will throw one aggressively.

blocks|key|4019431|text|您应该尽可能地捕获所有异常。总是可以通过一条简单的if语句来防止NullPointerException。其他一些例外，像大多数IOException一样，很难预防。除了使用try/catch块所需的样板外，如果您的类抛出异常，则将创建该异常的对象，并且必须对其进行垃圾回收……因此，通过不抛出异常，您还可以使您的VM更健康。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4019432|entityMap^0|P|2|W|K|1S|B|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

you should catch all exceptions you can. <code>NullPointerException</code>s can always be prevented with a simple <code>if</code> statement. some other exceptions, like most <code>IOException</code>s, are hard to be prevented. and besides the boilerplate needed to use a try/catch block, if your class throws an exception, an object of that exception will be created and it must be garbage collected... so by not throwing exceptions, you also make your VM healthier.

blocks|key|1266673|text|我希望我的所有异常向上移动，除非它们是次要的，然后我将吞下它们(例如:防止索赔条目死亡，因为电子邮件通知功能生成了NPE...我愿意接受NPE，并继续进行卡车运输，只要程序的真正肉抛出没有例外)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1266674|我使用这个方法来强制大多数Java的不可恢复的检查异常：|offset|length|style|BOLD|1266675|http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html|1266676|entityMap|0|LINK|mutability|MUTABLE|url^0|0|I|5|0|0|1P|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@$D|S|E|T|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|U|8|@]|9|@$D|V|E|W|1|X]]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|I]]]]

I want all of my exceptions to travel upwards unless they are minor then I will swallow them (ex: prevent a claim entry dieing because an email notification function generated a NPE... I would like to swallow that NPE and keep trucking on as long as the real meat of the program throws no exceptions).

I use this method to force most of Java's unrecoverable yet checked exceptions:

<a href="http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html" rel="nofollow noreferrer">http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html</a>

blocks|key|1266701|text|在你知道如何处理异常的地方捕捉它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1266702|你不应该到处检查(+foo+!=null)，只检查第一次使用foo的地方。在此之后，只需使用foo而不进行检查。如果在确定foo不是null之后，foo突然变成null，那么您就有大问题了。那么，一个例外是合适的。|1266703|try+{
+++foo();
}
catch+(FooException+e)+{
}|code-block|syntax|javascript|1266704|是一种糟糕的代码气味，应该避免|1266705|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Catch exceptions where you know how to deal with them.

You shouldn't check for (foo!=null) everywhere, check where foo is first used only. After that just use foo without checking. If foo suddenly becomes null after you've made sure it isn't null, you have big problems. An exception is appropriate then.

<pre><code>try {
 foo();
}
catch (FooException e) {
}
</code></pre>

is a bad code smell, and should be avoided

blocks|key|4864479|text|通常，当异常应该导致进程中止时，我会使用异常。当我要对问题做些什么并以某种方式恢复时，我会试图防止异常发生。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4864480|例如，如果一个参数被传递给子例程，而我合理地预期它可能为null，那么我就会检查它是否为null。例如，在现实生活中，空字符串通常等同于长度为零的字符串，我将在其中编写<+if+(s==null)+s=""；>。|4864481|但是，如果空字符串意味着发生了严重的错误，我们应该退出整个过程，并向用户显示"Panic+--+Abort+--+World+ending+soon“类型的消息，那么异常就非常方便。您可以在许多子例程的深层抛出异常，只需在顶部捕获它，显示消息，就完成了。|4864482|对于这样的情况，我经常创建自己的异常。我的许多程序中都有类似<抛出新的BadInputException("Customer+number+not+found")+>这样的代码，可以让我退出，显示一条消息，然后退出。这真的节省了IFs的深度嵌套和对子例程返回值的常量检查。|4864483|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|$]]

In general, I use exceptions when the exception should cause a process to abort. When I'm going to do something about the problem and recover in some way, I try to prevent the exception from ever happening.

Like, if a parameter is passed in to a subroutine and I reasonably expect that it might be null, I'll check it for null. In real life, for example, a null String often is equivalent to a zero-length String, in which I'll just write &lt; if (s==null) s=""; >. 

But if a null String means that something has gone badly wrong and we should just quit the whole process and display a "Panic -- Abort -- World ending soon" type of message to the user, then an exception is very handy. You can throw the exception way down deep inside many layers of subroutines, and just catch it at the top, display the message, and you're done.

I often create my own exceptions for such conditions. Many of my programs are sprinkled with code like &lt; throw new BadInputException("Customer number not found") > to just get me out, display a message, and quit. This really saves on deep nesting of IFs and constant checking of return values from subroutines.

blocks|key|1263059|text|我将检查方法开头的输入参数，如果它们不在应该传递给方法的范围内，则抛出IllegalArgumentException。这个想法是，这是一个编程错误，它应该被修复。现在比它在野外的时候要好。如果在方法中途遇到意外情况(列表中的null等)，我将记录一条致命消息并执行System.exit(2)。这又一次迫使你修复一个问题，而不是仅仅记录它并继续前进。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1263060|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|$]]

I will check the input parameters at the beginning of a method and throw an IllegalArgumentException if they are outside what should be passed to the method. The idea being that it's a programming error and it should be fixed. Better now than when it's out in the field. If in the middle of a method I get an unexpected condition (null in a list, etc) I will log a fatal message and do a System.exit(2). Again this forces you to fix an issue vs. just logging it and moving on.

blocks|key|800905|text|我尽可能地防止，但我会捕捉用户有影响的东西，例如，当他们输入错误类型的数据时。在Java中，我编写了一个类，它扩展了Scanner，并不断要求正确的输入，直到它有效为止。(来自CLI)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|800906|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|$]]

I prevent whenever possible, but I catch things the user has impact on, for example when they enter the wrong type of data. In Java, I have a class that I wrote which extends Scanner and keeps asking for proper input until it is valid. (From CLI)

blocks|key|4864585|text|一般来说，异常应该是一些异常，例如不可预见的或由于编程错误。问题是，在Java类库中有几个可疑的设计描述，所以你最终会得到像这样的习惯用法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4864586|class+Foo+{
++static+BufferedReader+in=new+BufferedReader(new+InputStreamReader(System.in));
++int+getInt()+throws+IOException+{
++++int+r=0;
++++for(;;)+{
++++++String+s=in.readLine();
++++++try+{
++++++++r=Integer.parseInt(s);
++++++++break;
++++++}
++++++catch(NumberFormatException+e)+{
++++++++System.out.println("Please+enter+a+valid+integer.");
++++++}
++++}
++++return+r;
++}
}|code-block|syntax|javascript|4864587|显然，这段代码并不完美(将在EOF上抛出一个NullPointerException+)，但它演示了对实际上并不异常的事情使用异常的问题。|4864588|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

In general, exceptions should be something exceptional, e.g. unforeseeable or due to programming errors.
The problem is, there are a couple of dubious design descisions in the Java class library so you end up with idioms like:

<pre><code>class Foo {
 static BufferedReader in=new BufferedReader(new InputStreamReader(System.in));
 int getInt() throws IOException {
 int r=0;
 for(;;) {
 String s=in.readLine();
 try {
 r=Integer.parseInt(s);
 break;
 }
 catch(NumberFormatException e) {
 System.out.println("Please enter a valid integer.");
 }
 }
 return r;
 }
}
</code></pre>

Clearly that code isn't perfect (will throw a NullPointerException on EOF) but it demonstrates the issue of using exceptions for things that aren't actually exceptional.

blocks|key|800988|text|我在整个代码中使用以下类来验证和中止处理：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|800989|​|800990|@Getter
@Setter
public+class+Abort<T>+{

++++private+boolean+abortProcessing;

++++private+T+response;
}|code-block|syntax|javascript|800991|800992|这样，您可以立即验证或捕获异常，记录它们并返回abort对象。|800993|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|P|8|@]|9|@]|A|$G|H]]|$1|I|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|R|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|M|$]]

I use the following class throughout my code to validate and abort processing:

<code>

<pre><code>@Getter
@Setter
public class Abort&lt;T&gt; {

 private boolean abortProcessing;

 private T response;
}
</code></pre>

</code>

This way you can validate or catch exceptions immediately, log them and return the abort object.

I am wondering how in practice other SOers tend to deal with and/or prevent exceptions.

In what situations do you prevent exceptions, and how? 
In what situations do you catch exceptions?

I usually prevent 'NullPointerExceptions' (and other similar ones) by, well, essentially saying <code>if(foo!=null) {...}</code>

I find that in most situations this is less bulky than everything involved in using a try-catch block.

I use try-catch blocks when the potential exceptions are more complex, or more numerous.

Preventing exceptions vs. catching exceptions in Java

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我想知道在实践中其他SOers倾向于如何处理和/或防止异常。在什么情况下，如何防止异常？在什么情况下会捕获异常？我通常通过，嗯，本质上说if(foo!=null) {...}来阻止'NullPointerExceptions‘(和其他类似的我发现在大多数情况下，这比使用try-catch块所涉及的一切都要小。当潜在的异...

问在Java中预防异常与捕获异常
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Java中预防异常与捕获异常EN