Java中main方法为何不宜直接抛出Exception异常？

本文共计729个文字，预计阅读时间需要3分钟。

分析：为什么说main方法不应该直接抛出异常？（注意，这里说的是不应该而不是不能，main方法是可以直接抛出异常的）。

对于这个问题，我们需要从两个角度来看待：

1. 从编程规范角度：在编程实践中，通常建议避免在main方法中直接抛出异常。这是因为main方法是程序的入口点，它负责启动整个程序的执行。如果在main方法中直接抛出异常，可能会导致程序无法正常运行，甚至无法启动。因此，从规范的角度来说，main方法应该尽量避免直接抛出异常。

2. 从开发角度：对于开发人员来说，在main方法中抛出异常有时是必要的。例如，当程序启动时需要检查一些前置条件，如果条件不满足，则可以抛出异常来阻止程序继续执行。在这种情况下，main方法抛出异常是一种合理的做法。

综上所述，对于是否应该在main方法中直接抛出异常，需要根据具体情况来决定。从规范的角度来看，建议避免直接抛出异常；但从开发的角度来看，有时直接抛出异常是必要的。

分析

为什么说main不应该直接抛出异常（注意，这里说的是“不应该”而不是“不能”，main方法是可以直接抛出异常的）？我个人觉得这个事情要两看，对于开发来说在main中抛异常还真的比较直观且方便调试。但事实上对于已经在运行的程序来说在main直接抛出异常会导致某些后续处理无法完成。

举个极端一点的例子，假如现在用到比较原始的jdbc连接查询数据。若在这个过程中发生异常并在main函数中直接抛出后结束，数据库连接将无法释放。

这时有的小伙伴会说”这都已经是main方法了，即使不用finally去处理也没有关系吧。反正程序结束后数据库回话也消失了”。的确，程序结束之后数据库会话也就结束了，但万一这个数据库处理过程是一个长事务处理（现象上像卡死但实际上还在运行，只是耗时较长）。这时，就需要手动发送一个断开连接的标识“告知”数据库，不然会话就会挂起直到数据库连接超时才会结束。但一般来说运维人员为了避免“超时时间过短”（著名的“com.MySQL.jdbc.CommunicationsException: The last packet successfully received from the server was xxxx seconds ago.”）异常，在设置数据库参数时将timeout值设得很高。

以至于在过往我们在某些情况下关闭了程序，但是数据库连接没有释放就是这个原因引起的......有点扯远了，因此我个人觉得throws是可以的，但最好在关键的代码中使用try catch来进行处理。

结论

对于以上说到的情况，我的main方法中采用try catch方法捕获异常：

public static void main(String args[]) { try { doSomething(); } catch (Throwable t) { log.error(t); System.exit(1); }}