我一直在编写Java代码。但有时候，我不知道应该何时抛出异常、何时捕获异常。我正在处理一个有很多方法的项目。层次结构如下：
Method A will call Method B and Method B will call some Method C and Method C will call Method D and Method E.
目前我正在做的是-在所有方法中抛出异常，然后在方法A中捕获并记录为错误日志。但我不确定这是否是正确的方式？还是应该开始在所有方法中捕获异常？因此，在何时捕获异常与何时抛出异常之间存在困惑。我知道这是一个愚蠢的问题，但不知何故，我仍然难以理解这个重要概念。
能否有人给我一个详细的示例来说明何时捕获异常与何时抛出异常，以便我的概念得到清晰？在我的情况下，我应该继续抛出异常，然后在主调用的A方法中捕获它吗？
当你在知道该如何处理异常的方法中时，应该捕获异常。
例如，暂且不考虑实际工作方式，假设你正在编写一个用于打开和读取文件的库。
因此，你有一个类，比如：
public class FileInputStream extends InputStream {
public FileInputStream(String filename) { }
}
现在，假设文件不存在。你应该怎么办？如果你很难想出答案，那是因为没有一个... FileInputStream 不知道该如何处理这个问题。所以它将问题上抛，即：
public class FileInputStream extends InputStream {
public FileInputStream(String filename) throws FileNotFoundException { }
}
现在，假设有人正在使用你的库。他们可能有这样的代码：
public class Main {
public static void main(String... args) {
String filename = "foo.txt";
try {
FileInputStream fs = new FileInputStream(filename);
// The rest of the code
} catch (FileNotFoundException e) {
System.err.println("Unable to find input file: " + filename);
System.err.println("Terminating...");
System.exit(3);
}
}
}
在这里，程序员知道该做什么，因此他们捕获异常并处理异常。
main 方法中，那里真的没有太多事情可做。显然，在代码深处强制退出 JVM 是不明智的。 - durron597在两种情况下应该捕获异常。
这是你与第三方代码集成的级别，例如ORM工具或执行IO操作（访问HTTP资源、读取文件、保存到数据库等）的任何库。也就是说，离开应用程序原生代码与其他组件交互的级别。
在这个级别上，不受你控制的意外问题可能会发生，例如连接失败和文件被锁定。
你可能想通过捕获TimeoutException来处理数据库连接故障，以便几秒钟后重试。同样，当访问文件时出现异常，文件可能正在被进程锁定，但在下一时刻可用。
在这种情况下，以下是指南：
SqlTimeoutException或IOException。永远不要处理通用异常（类型为Exception的异常）这将是在异常直接抛出到用户之前可以处理异常的最后一个位置。
您的目标是记录错误并将详细信息发送给程序员，以便他们可以识别和纠正错误。添加尽可能多的信息，记录下来，然后向用户显示道歉消息，特别是如果这是软件中的错误，他们可能无法做任何事情。
在这种第二种情况下的指导方针是：
首先，异常代表不可逆转的错误。它们代表系统中的错误、程序员犯的错误或应用程序无法控制的情况。
在这些情况下，通常用户无法做什么。因此，你唯一能做的就是记录错误，采取必要的补救措施，并向用户道歉。如果是程序员犯的错误，最好让他们知道并修复它，努力实现更稳定的版本。在表示层中，情况又有所不同，您希望用户提供无效参数。在这种情况下，只需显示友好的消息而不是抛出异常。
如https://roaddd.com/the-only-two-cases-when-you-should-handle-exceptions/中所述。
LoggedException），以在更高的层次上捕获它，该异常类型表示“此异常已经被记录，因此不要再次记录它，但您仍然需要生成向用户的道歉消息”。 - Jacob Stamm当函数遭遇到故障或错误时，应该抛出异常。
函数是一个工作单元，故障应该根据对功能的影响视为错误或其他类型。在函数f内部，如果一个故障阻止了f满足任何调用方的前置条件、实现任何f自身的后置条件或重新确立任何f负责维护的不变量，则该故障被视为错误。
有三种不同的错误：
/* gets called by an actionListener when user clicks a menu etc... */
public URL openTheDB() {
URL urlForTheDB = MyCoolDialogUtils.getMeAURL(URL somePreviousOneToFillInTheStart);
try {
verifyDBExists(urlForTheDB);
// this may call a bunch of deep nested calls that all can throw exceptions
// let them trickle up to here
// if it succeeded, return the URL
return urlForTheDB;
}
catch (NoDBExeption ndbe) {
String message = "Sorry, the DB does not exist at " + URL;
boolean tryAgain = MyCoolDialogUtils.error(message);
if (tryAgain)
return openTheDB();
else
return null; // user said cancel...
}
catch (IOException joe) {
// maybe the network is down, aliens have landed
// create a reasonable message and show a dialog
}
}
throw new RuntimeException(checked,"Could not retrieve contact " + id);
采用这种方法，您的GUI或业务层的方法签名不会因为必须声明与数据库相关的异常而变得混乱。
下面举个实际例子：
假设我的代码工作是自动续订许多保险单。该架构支持GUI手动触发一个保单的续订。同时，假设某个保单的评级区域的邮政编码在数据库中损坏了。
我想要实现的错误日志示例如下所示。
日志消息：由于错误，将策略1234标记为需要手动干预：
来自堆栈跟踪：续订策略1234时出错。正在回滚事务...此catch还将覆盖保存错误或生成信函等错误。
来自堆栈跟踪：原因：评级策略1234错误...此catch将捕获检索许多其他对象和算法错误（例如NPE）等错误。
来自堆栈跟踪：原因：检索评级区域73932错误...
来自堆栈跟踪：原因：JPA：字段“postcode”中出现意外的null
在可能的最低级别处理异常。如果方法无法正确处理异常，则应将其抛出。