blocks|key|3126937|text|在Java+API文档中：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3126938|3126939|类Exception及其子类是Throwable的一种形式，表示合理的应用程序可能希望捕获的条件。|blockquote|offset|length|style|CODE|3126940|3126941|Error是Throwable的子类，用于指示合理的应用程序不应尝试捕获的严重问题。|3126942|3126943|错误通常是低级别的(例如，由虚拟机引发)，并且不应该被应用程序捕获，因为合理的继续可能是不可能的。|3126944|entityMap^0|0|0|1|9|F|9|0|0|0|5|6|9|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|T|8|@$F|U|G|V|H|I]|$F|W|G|X|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Z|8|@$F|10|G|11|H|I]|$F|12|G|13|H|I]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|15|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|Q|$]]

From the Java API documentation:
<blockquote>
The class <code>Exception</code> and its subclasses are a form of <code>Throwable</code> that indicates conditions that a reasonable application might want to catch.
An <code>Error</code> is a subclass of <code>Throwable</code> that indicates serious problems that a reasonable application should not try to catch.
</blockquote>
Errors usually are low-level (eg., raised by the virtual machine) and should not be caught by the application since reasonable continuation might not be possible.

blocks|key|348574|text|通常情况下，错误是您无法恢复的问题，如OutOfMemoryError。捕获它们没有任何作用，所以通常应该让它们逃脱，并使虚拟机崩溃。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|348575|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/javase/6/docs/api/java/lang/OutOfMemoryError.html^0|J|G|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Usually Errors are problems you cannot possibly recover from, like <a href="http://java.sun.com/javase/6/docs/api/java/lang/OutOfMemoryError.html" rel="noreferrer">OutOfMemoryError</a>. There's nothing to do by catching them, so you should usually let them escape, and bring down the virtual machine.

blocks|key|352118|text|通常，在编程时，您应该只捕获特定的异常(如IOException)。在许多程序中，你可以看到一个非常高的级别|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|352119|try+{
++++...
}+catch(Exception+e)+{
++++...
}|code-block|syntax|javascript|352120|这会捕获所有可以恢复的错误，以及所有指示代码中存在错误的错误，例如InvalidArgumentException、NullPointerException。然后，您可以自动发送eMail、显示消息框或任何您喜欢的内容，因为JavaVM本身仍然工作正常。|352121|从Error派生的任何东西都是非常糟糕的，你不能做任何反对的事情。问题是，捕获OutOfMemoryError或VirtualMachineError是否有意义。(这是JavaVM本身的一个错误，那么您可能甚至无法显示消息框或发送eMail+)|352122|您可能不应该从Error派生类，而应该从Exception或RuntimeException派生。|352123|entityMap^0|L|B|0|0|X|O|1M|K|0|1|5|13|G|1K|J|0|7|5|K|9|U|G|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|V|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|M|3|N|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]|$9|16|A|17|B|C]]|D|@]|E|$]]|$1|O|3|P|5|6|7|18|8|@$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|1F|8|@]|D|@]|E|$]]]|R|$]]

Normally when programming, you should only catch a specific exception (such as <code>IOException</code>). In a lot of programs you can see a very toplevel

<pre><code>try {
 ...
} catch(Exception e) {
 ...
}
</code></pre>

That catches all errors which could be recoverable and all those which indicate a bug in your code, e.g. <code>InvalidArgumentException</code>, <code>NullPointerException</code>. You can then automatically send an eMail, display a message box or whatever you like, since the JavaVM itself is still working fine.

Everything derived from <code>Error</code> is something very bad, you can't do anything against. The question is, if it makes sense to catch a <code>OutOfMemoryError</code> or a <code>VirtualMachineError</code>. (It is a error in the JavaVM itself, probably you can't even display a message box or send an eMail then)

You should probably not a class derived from <code>Error</code>, you should derive from <code>Exception</code> or <code>RuntimeException</code>.

blocks|key|3126977|text|略有离题，但您可能还想查看有关异常的this+very+good+article。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3126978|entityMap|0|LINK|mutability|MUTABLE|url|http://www.oracle.com/technology/pub/articles/dev2arch/2006/11/effective-exceptions.html^0|I|M|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Slightly off topic, but you may also want to look at <a href="http://www.oracle.com/technology/pub/articles/dev2arch/2006/11/effective-exceptions.html" rel="nofollow noreferrer">this very good article</a> about exceptions.

blocks|key|3126990|text|这在一定程度上取决于您在捕获错误后如何处理它。一般来说，捕获错误可能不应该被视为“正常”异常流的一部分。如果你真的捕获了一个错误，你不应该想着“像什么都没有发生一样继续下去”，因为JVM+(和各种库)会使用错误作为一种信号，表示“发生了真正严重的事情，我们需要尽快关闭”。一般来说，当他们告诉你世界末日即将来临时，最好还是听从他们的话。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3126991|另一个问题是，错误的可恢复性或不可恢复性可能取决于特定的虚拟机，这是您可能控制或无法控制的东西。|3126992|也就是说，在少数情况下，捕获错误或至少某些子类是安全和/或可取的：|3126993|在某些情况下，你确实想要停止正常的流程:例如，如果你在一个Servlet中，你可能不希望Servlet运行器的默认异常处理程序向全世界宣布你已经有了一个it.|3126994|Occasionally，，无论你能不能从中恢复，|unordered-list-item|3126995|都会抛出一个错误。例如，如果在尝试分配数组时发生OutOfMemoryError，至少在Hotspot中，似乎可以安全地从中恢复。(当然，在其他情况下，可能会抛出不安全尝试的OutOfMemoryError。)|3126996|3126997|3126998|所以底线是:如果你确实捕获了Throwable/Error而不是Exception，那么它应该是一个你知道你正在“做一些特殊的”的定义良好的情况。|offset|length|style|BOLD|3126999|编辑:这可能是显而易见的，但我忘了说，在实践中，捕获JVM可能不会在错误时实际调用子句。我肯定看到过Hotspot巧妙地掩盖了捕获某些OutOfMemoryErrors和NoClassDefFoundError的尝试。|3127000|entityMap^0|0|0|0|0|0|0|0|0|1T|8|0|0|31|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|12|8|@]|9|@]|A|$]]|$1|K|3|L|5|J|7|13|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|16|8|@$Q|17|R|18|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|19|8|@$Q|1A|R|1B|S|T]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|X|$]]

It all depends a bit on what you're going to do with an Error once you've caught it. In general, catching Errors probably shouldn't be seen as part of your "normal" exception flow. If you do catch one, you shouldn't be thinking about "carrying on as though nothing has happened", because the JVM (and various libraries) will use Errors as a way of signalling that "something really serious has happened and we need to shut down as soon as possible". In general, it's best to listen to them when they're telling you the end is nigh.

Another issue is that the recoverability or not from an Error may depend on the particular virtual machine, which is something you may or not have control over.

That said, there are a few corner cases where it is safe and/or desirable to catch Errors, or at least certain subclasses:

<ul>
<li>There are cases where you really do want to stop the normal course of flow: e.g. if you're in a Servlet, you might not want the Servlet runner's default exception handler to announce to the world that you've had an OutOfMemoryError, whether or not you can recover from it.</li>
<li>Occasionally, an Error will be thrown in cases where the JVM can cleanly recover from the cause of the error. For example, if an OutOfMemoryError occurs while attempting to allocate an array, in Hotspot at least, it seems you can safely recover from this. (There are of course other cases where an OutOfMemoryError could be thrown where it isn't safe to try and plough on.)</li>
</ul>

So the bottom line is: if you do catch Throwable/Error rather than Exception, it should be a well-defined case where you know you're "doing something special".

Edit: Possibly this is obvious, but I forgot to say that in practice, the JVM might not actually invoke your catch clause on an Error. I've definitely seen Hotspot glibly gloss over attempts to catch certain OutOfMemoryErrors and NoClassDefFoundError.

blocks|key|3127037|text|我知道这可能是违反直觉的，但仅仅因为你可以捕获所有类型的异常、抛出和错误，不是就意味着你应该这样做。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3127038|过度积极地捕获java.lang.Exception可能会导致应用程序中出现一些严重的错误-因为意外的异常永远不会冒泡，在开发/测试等过程中也不会被捕获。|3127039|最佳实践:仅捕获|3127040|3127041|异常，您可以处理捕获|ordered-list-item|3127042|所必需的|3127043|异常|3127044|entityMap^0|11|2|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|Z|8|@]|D|@]|E|$]]|$1|N|3|O|5|M|7|10|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|11|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|S|$]]

I know it might be counter-intuitive, but just because you can catch all sorts of Exceptions and Throwables and Errors does not mean you should.

Over-aggressive catching of java.lang.Exception can lead to some serious bugs in applications - because unexpected Exceptions never bubble up, are never caught during development/testing, etc.

Best practice: only catch 

<ol>
<li>Exceptions that you can handle </li>
<li>Exceptions that are necessary to catch</li>
</ol>

blocks|key|3339888|text|不要+Throwable或Error，通常你也不应该简单地捕获一个通用的Exception。Error通常是最合理的程序不可能恢复的东西。如果您知道发生了什么，您可能能够从一个特定的错误中恢复，但在这种情况下，您应该只捕获一个特定的错误，而不是一般的所有错误。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3339889|不捕获Error的一个很好的理由是因为ThreadDeath。ThreadDeath是一个相当正常的事件，理论上可以从任何地方抛出(像JVM本身这样的其他进程可以生成它)，它的全部目的就是杀死您的线程。ThreadDeath显式地是一个Error而不是Exception，因为太多的人捕获所有的Exception。如果你曾经捕获ThreadDeath，你必须重新抛出它，这样你的线程才能真正死掉。|3339890|如果您可以控制源代码，那么应该将其重构为抛出Exception而不是Error。如果你不这样做，你可能应该打电话给供应商投诉。Error应该只保留给那些没有可能从它们恢复的终端。|3339891|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/javase/6/docs/api/java/lang/ThreadDeath.html^0|3|9|D|5|10|9|1A|5|0|3|5|J|B|V|B|2T|B|3A|5|3I|9|43|9|4K|B|J|B|0|0|M|9|Y|5|1R|5|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|10|8|@$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]|$9|17|A|18|B|C]|$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]]|D|@$9|1H|A|1I|1|1J]]|E|$]]|$1|H|3|I|5|6|7|1K|8|@$9|1L|A|1M|B|C]|$9|1N|A|1O|B|C]|$9|1P|A|1Q|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1R|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

Do NOT ever catch <code>Throwable</code> or <code>Error</code> and you should generally not simply catch a generic <code>Exception</code> either. <code>Error</code>s are generally things that most reasonable programs cannot possibly recover from. If you know what is going on, you might be able to recover from one specific error, but in that case, you should catch only that one particular error and not all errors in general.

A good reason not to catch <code>Error</code> is because of <a href="http://java.sun.com/javase/6/docs/api/java/lang/ThreadDeath.html" rel="nofollow noreferrer"><code>ThreadDeath</code></a>. <code>ThreadDeath</code> is a fairly normal occurrence that can theoretically be thrown from anywhere (other processes like the JVM itself can generate it), and the whole point of it is to kill your thread. <code>ThreadDeath</code> is explicitly an <code>Error</code> rather than an <code>Exception</code> because too many people catch all <code>Exception</code>s. If you ever were to catch <code>ThreadDeath</code>, you must rethrow it so that your thread actually dies.

If you have control over the source, it should probably be restructured to throw an <code>Exception</code> rather than an <code>Error</code>. If you don't, you should probably call to the vendor and complain. <code>Error</code>s should be reserved for only things that are terminal with no possible way to recover from them.

blocks|key|3127116|text|我将走一条与其他人略有不同的路线。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3127117|在很多情况下，你会想要捕获Throwable+(主要是为了记录/报告发生了一些不好的事情)。|3127118|但是，您需要小心，并重新抛出您无法处理的任何东西。|3127119|对于ThreadDeath来说尤其如此。|3127120|如果您曾经捕获Throwable，请确保执行以下操作：|3127121|try+{
++++...
}+catch+(SomeExceptionYouCanDoSomethingWith+e)+{
++++//+handle+it
}+catch+(ThreadDeath+t)+{
++++throw+t;
}+catch+(Throwable+t)+{
++++//+log+&+rethrow
}|code-block|syntax|javascript|3127122|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|V|8|@]|9|@]|A|$M|N]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I'll go a slightly different route from others.

There are many cases where you would want to catch Throwable (mainly to log/report that something evil happened).

However, you need to be careful and rethrow anything that you cannot deal with.

This is especially true of ThreadDeath.

If you ever catch Throwable, be sure to do the following:

<pre><code>try {
 ...
} catch (SomeExceptionYouCanDoSomethingWith e) {
 // handle it
} catch (ThreadDeath t) {
 throw t;
} catch (Throwable t) {
 // log &amp; rethrow
}
</code></pre>

blocks|key|348638|text|这篇文章不会让那些“检查异常不好”的人高兴。然而，我的答案是，Java异常是如何按照创建该语言的人的定义来使用的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|348639|快速参考图：|348640|348641|Throwable+-从不捕获此|unordered-list-item|348642|错误-指示VM错误-从不捕获|348643|-指示程序员错误-从不捕获此|348644|异常-从不捕获此|348645|348646|不应该捕获Exception的原因是它捕获了所有的子类，包括RuntimeException。|348647|你不应该捕获Throwable的原因是它捕获了所有的子类，包括Error和Exception。|348648|上面的“规则”有一些例外(不是双关语)：|348649|您正在使用的|348650|代码(来自第三方)引发Throwable或Exception|348651|You正在运行不受信任的代码，如果出现异常，可能会导致您的程序崩溃。|348652|348653|对于第二个异常，通常将main、事件处理代码和线程与catch一起包装到Throwable，然后检查异常的实际类型并适当地处理它。|348654|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|18|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|19|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1A|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|1B|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1D|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1E|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1F|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1G|8|@]|9|@]|A|$]]|$1|W|3|X|5|G|7|1H|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|G|7|1I|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1K|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|14|$]]

This post won't make the "checked exceptions are bad" people happy. However, what I am basing my answer on is how Java exceptions are intended to be used as defined by the people that created the language.

Quick reference chart:

<ul>
<li>Throwable - never catch this</li>
<li>Error - indicates a VM error - never catch this</li>
<li>RuntimeException - indicated a programmer error - never catch this</li>
<li>Exception - never catch this</li>
</ul>

The reason you should not catch Exception is that it catches all of the subclasses, including RuntimeException.

The reason you should not catch Throwable is that it catches all of the subclasses, including Error and Exception.

There are exceptions (no pun intended) to the above "rules":

<ul>
<li>Code you are working with (from a 3rd party) throws Throwable or Exception</li>
<li>You are running untrusted code that could cause your program to crash if it thew an exception.</li>
</ul>

For the second one usually it is enough to wrap main, event handling code, and threads with the catch to Throwable and then check the actual type of the exception and deal with it as appropriate.

blocks|key|3339970|text|至少在一种情况下，我认为您可能必须捕获可抛出的异常或通用异常-如果您正在运行单独的线程来执行任务，您可能想知道该线程的"run“方法是否捕获了一些异常。在这种情况下，您可能会这样做：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3339971|public+void+run()+{
+++try+{
+++++++...
+++}
+++catch(Throwable+t)+{
+++++++threadCompletionError+=+t;
+++}
}|code-block|syntax|javascript|3339972|我真的不确定这是不是最好的方法，但它是有效的。我遇到一个由JVM引发的"ClassNotFound“错误，这是一个错误而不是异常。如果我让异常被抛出，我不确定如何在调用线程中捕获它(可能有一个方法，但我还不知道)。|3339973|至于ThreadDeath方法，不要调用"Thread.stop()“方法。调用Thread.interrupt并让您的线程检查是否有人中断了它。|3339974|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

There's at least one case when I think you may have to catch a throwable or a generic exception - if you're running a separate thread to perform a task, you may want to know if the "run" method of the thread has catched some exception or not. In that case, you probably will do something like this:

<pre><code>
public void run() {
 try {
 ...
 }
 catch(Throwable t) {
 threadCompletionError = t;
 }
}
</code></pre>

I am really not sure if it's the best approach, but it works. And I was having a "ClassNotFound" error being raised by the JVM, and it's an error and not an exception. If I let the exception be thrown, I am not sure how to catch it in the calling thread (probably there's a method but I don't know about it - yet).

As for the ThreadDeath method, don't call the "Thread.stop()" method. Call Thread.interrupt and have your thread to check if it was interrupted by someone.

blocks|key|3127217|text|一般来说，尝试捕获错误是合理的，只要这样才能正确地报告错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3127218|然而，我相信在某些情况下，捕获错误而不报告它是合适的。我指的是UnsatisfiedLinkError。在JAI中，出于性能原因，库使用一些本地库来实现大多数运算符，然而，如果库无法加载(不存在，格式错误，平台不支持)，库仍将运行，因为它将退回到仅java模式。|3127219|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 it would be reasonable to try to catch Errors if only so that can be properly reported.

However, I believe there are cases when it would be appropriate to catch an Error and not report it. I'm referring to UnsatisfiedLinkError. In JAI the library uses some native libraries to implement most of the operators for performance reasons, however if the library fails to load (doesnt exist, wrong format, unsupported platform) the library will still function because it will fall back into a java only mode.

blocks|key|352303|text|捕获错误是没有意义的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|352304|错误用于指示应用程序中出现了真正的错误，应该重新启动应用程序。|352305|例如，一个常见的错误是|352306|java.lang.OutOfMemoryError|code-block|syntax|javascript|352307|当发生这种情况时，您无法执行任何操作。NOTHING。已经太晚了，JVM已经用尽了所有的选择来获得更多的内存，但这是不可能的。|352308|请参阅另一个答案以了解有关three+kinds+of+exceptions的更多信息。|352309|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/462501/exception-other-than-runtimeexception/462745#462745^0|2|2|0|0|0|0|J|7|0|D|P|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|13|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|14|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|15|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|16|8|@$9|17|A|18|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|19|8|@]|D|@$9|1A|A|1B|1|1C]]|E|$]]|$1|S|3|-4|5|6|7|1D|8|@]|D|@]|E|$]]]|T|$U|$5|V|W|X|E|$Y|Z]]]]

There is no point in catching Error. 

Errors are used to indicate something went really wrong in your application and it should be restarted. 

For instance one common error is 

<pre><code>java.lang.OutOfMemoryError
</code></pre>

There is NOTHING you can do when that happens. Is already too late, the JVM has exhausted all its options to get more memory but it is impossible. 

See this other answer to understand more about the <a href="https://stackoverflow.com/questions/462501/exception-other-than-runtimeexception/462745#462745">three kinds of exceptions</a>.

blocks|key|3127283|text|许多其他的答案都过于狭隘地看待事物。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3127284|正如他们所说，如果您正在编写应用程序代码，则不应捕获Throwable。您对此无能为力，所以最好让周围的系统(JVM或框架)来处理这些问题。|3127285|但是，如果您正在编写“系统代码”，比如框架或其他低级代码，那么您可能非常希望捕获Throwable。原因是尝试报告异常，可能是在日志文件中。在某些情况下，您的日志记录将失败，但在大多数情况下，它将成功，并且您将获得解决问题所需的信息。一旦您进行了日志记录尝试，您就应该重新抛出、终止当前线程或退出整个JVM。|3127286|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|$]]

A lot of the other answers are looking at things too narrowly.

As they say, if you are writing application code, you should not catch Throwable. You can't do anything about it, so allowing the surrounding system (JVM or framework) to handle these issues is best.

However, if you are writing "system code", like a framework or other low-level code then you may very well want to catch Throwable. The reason is to attempt to report the exception, perhaps in a log file. In some cases your logging will fail, but in most cases it will succeed and you will have the information you need to resolve the issue. Once you have made your logging attempt you should then either rethrow, kill the current thread, or exit the entire JVM.

blocks|key|3340163|text|为什么不把他们都抓起来呢？然后记录它们，至少你知道你有一个错误。因此，捕获Throwable/s比仅捕获Exception/s要好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3340164|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|$]]

Why not catch them all? Then log them, at least you know you have an error. So better catch Throwable/s than Exception/s only.

We recently had a problem with a Java server application where the application was throwing Errors which were not caught because Error is a separate subclass of Throwable and we were only catching Exceptions.

We solved the immediate problem by catching Throwables rather than Exceptions, but this got me thinking as to why you would ever want to catch Exceptions, rather than Throwables, because you would then miss the Errors.

So, why would you want to catch Exceptions, when you can catch Throwables?

Why catch Exceptions in Java, when you can catch Throwables?

日志文件

服务器

虚拟机

Java

我们最近遇到了一个Java服务器应用程序的问题，该应用程序抛出的错误没有被捕获，因为Error是Throwable的一个单独的子类，而我们只捕获异常。我们通过捕获Throwables而不是异常解决了直接的问题，但这让我思考为什么你会想要捕获异常，而不是Throwables，因为那样你就会错过错误。那么，既然可以捕获Th...

问既然可以捕获Throwables，为什么还要在Java中捕获异常呢？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问既然可以捕获Throwables，为什么还要在Java中捕获异常呢？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问既然可以捕获Throwables，为什么还要在Java中捕获异常呢？
EN