长期尝试声明
将大部分代码放在try statement是否有任何缺点。 如果我做了一些需要try statement事情，我通常最终会在try语句中为该函数做很多工作，因为我经常在那里声明我的变量，如果我这样做，就不能在那个范围之外使用它们。 这是常见的并被接受了吗？ 人们通常在没有初始化之前声明变量，所以他们没有在try statement做所有事情（包括调用其他函数）吗？ 或者它是否很长并不重要？
一种方法应该做一件事并且做得好。 在这种情况下，您的方法做了两件事：业务逻辑和error handling：
public Foo bar() { try { //business logic that may throw //... //end even more } catch(BuzzException e) { //Error handling } }
我经常发现自己将try块的内容提取到一个单独的方法中而没有error handling：
public Foo bar() { try { return unsafeBar(); } catch(BuzzException e) { //Error handling } } public Foo unsafeBar() throws BuzzException { //business logic that may throw //... //end even more }
重要的是，如果它很长，但不是你想的原因。 这很重要，因为它使您的代码难以阅读和测试。 你最好将它重构为几种方法：
public void doComplexThing() { try { SomeObject o1 = doSomethingLessComplex(); SomeOtherObject o2 = doSomethingElse(o1); doFinalThing(o2); } catch (SomeException e) { // handle the exception } }
如果try块变得有点长，那么将实际抛出exception的调用隔离到自己的方法中是个好主意。 这样你就可以单独解决在该块中抛出的几种exception。
如果你试图测试或发现一个“神秘”的错误，那么在try使用普通旧catch(Exception ex)会覆盖许多exception会引起头痛。 这并不是说适当的资源/流处理，这是许多检查过的例外。
作为一名高级程序员，我理解使用try catch完全优于抛出exception与代码整洁的语句之间的混淆。
在这里，我倾向于try catch over the statements that need it 。
首先让我们了解try catch的必要性。 我们捕获exception，因为我们想在这里和现在处理它。 如果我们不把它扔给来电者。 我们抛弃它，以便我们不会忘记稍后处理它。 从来没有， Oh!, let me finish this method and then I will worry about the exception handling later 。 在编写代码时这样做，想一想，是否需要打印错误并返回null，或者您是否需要用户知道搞砸了什么？ 是否要整合所有连接问题以recycle the connection消息？ 如果是，则抛出您自己的自定义exception。 但一定要处理它。 忽略并执行错误的exception处理是项目维护和客户心脏燃烧成本增加的根本原因。 这是好产品和草率产品之间的区别。
至于代码整洁，我发现catch块中的注释使得它值得你花时间。 是的，会有一些高级的人不理解捕获确切语句的重要性，并且会直接捕获catch (Exception e) 。 可怜，我会说。 但是在编码时你应该坚持自己的道德规范。 做得对，做到这一点。