这种Java异常风格是一种糟糕的做法吗？

在一个方法中有多个try并像这样构造代码是否被认为是不好的做法

public void whatever() {
   try {
     methodThatMayThrowIOException();
   } catch(IOException io) {
     // do something with exception here
   }

   // do more stuff here that won't throw exceptions

   try {
     methodThatMayThrowCustomException();
   } catch(CustomException ce) {
     // do something with custom exception here
   }
}

---

看起来没问题，但这取决于可能通过异常的

方法和可能通过自定义异常的
方法做什么，以及第一个方法（
方法可能通过异常的
方法）的失败是否会导致整个
方法失败，只要你真的做了一些有用的事情来处理你发现的异常
 如果该方法可以继续执行，即使发生指定的异常，也不会出现任何问题，那么应该可以

如果异常会在方法的下一行引起问题，我会让它冒泡。
不，不是。捕捉可能抛出的特定异常是一个很好的方法，当然比这更好：

public void whatever {
    try {
        methodThatMayThrowIOException();
        // do more stuff here that won't throw exceptions
        methodThatMayThrowCustomException();
    } catch(ParentException e) {
        // do something with custom exception here
    }
}

这取决于你想完成什么。如果代码块应作为块执行，则通常将代码块封装在单个try-catch块中，如果发生异常，则根本不执行。如果不是这样的话，那么我认为最好将抛出不同异常的不同代码块隔离到不同的try-catch块中，并进行“在这里做更多不抛出异常的事情”。只是一个想法
 这实际上取决于在引发IOException时您计划做什么。你的风格可以让你做更多的事情，但如果你实际上并不打算利用这一点，那么通过使用标准的习惯用法，你的意图就会更加清晰

public void whatever {
   try {
     methodThatMayThrowIOException();
     // do more stuff here that won't throw exceptions
     methodThatMayThrowCustomException();
   } catch(IOException io) {
     // do something with io exception here
   } catch(CustomException ce) {
     // do something with custom exception here
   }
}

在这里，您可以很快看出，如果抛出IOException，那么您只执行catch块内部的操作，而不执行其他操作。
AFAICS，这没有问题。然而，两个尝试捕捉的方法刺痛了我的眼睛。如果你也这么认为，我建议你用一种合适的方式重构它。
不。这是一种很好的做法，可以缩小引发某种异常的范围。我在代码中做了很多

但是，如果您确定在一个try…catch块中，某些类型的异常只会由唯一的函数引发，将它们放在同一个try块中也可以。
我个人认为它看起来很混乱。我宁愿只试一次，用我需要的尽可能多的挡块。我不在乎在一个方法中使用多个try/catch序列。
您的代码读起来像这样，因为您想执行第1部分（并在必要时解析、捕获
IOException
），执行无异常部分，然后执行可能通过自定义异常执行的
方法您的代码不能以任何其他方式编写并保留相同的功能。这有点夸张，但任何其他版本在表面上都会有所不同

这是不一样的：

public void whatever {
   try {
     methodThatMayThrowIOException();
     // do more stuff here that won't throw exceptions
     methodThatMayThrowCustomException();
   } catch(IOException io) {
     // do something with io exception here
   } catch(CustomException ce) {
     // do something with custom exception here
   }
}

如果抛出任何异常，它将以完全不同的方式执行。如果您需要按顺序从第1部分恢复，请在任何情况下点击第2部分，然后继续到第3部分，您实际上无法以任何其他方式编写代码

拥有两个catch块并没有什么错，尽管将导致IOException的内容与抛出CustomException的内容混合在一起可能会导致关注点的混合，从而使代码难以理解。但事实上，这不仅是有效的，而且是做你正在做的事情的唯一方法。
为什么这应该是一种不好的做法？看起来很有条理（我的意思是，你只能在你必须的地方抓到）。我唯一想做的就是抛出代码之外的异常> < <代码> >，因为我更喜欢抛出异常和看到错误，越快越好（只在演示图层中捕获异常）。如果IOException可以从中恢复，这是一种好的样式，如果不能，这是一种非常糟糕的样式。IOException只是一个例子。我想知道在一个方法中有多个try。如果在方法MaythrowOeException（）抛出一个异常（该异常已被处理）后，可以通过CustomException（）完全正常工作，这怎么会更糟糕？此外，在示例中，根本不确定IOException和CustomException是否有一个共同的父级（除了异常，但捕获异常不是一个好主意）@Thomas Lötzer:什么？
方法可能会通过自定义异常（）执行如果
方法可能会通过自定义异常（）执行，则根本不会执行
方法
抛出一个异常……如果你在方法内部谈论一个try-catch，那么你是在做假设，我认为这超出了问题的范围。@Valentin Rocher:没有捕获一个普通的父对象（即使这是唯一的异常），这正是我回答的重点。好吧，我误读了你的答案。你能做一个虚拟编辑，这样我就删除了下一票吗？好吧，我自己做了一个虚拟编辑，删除了下一票。对不起！他已经利用了这一点，拥有了第二和第三部分。是的，但是第一个抓块可以返回/抛出，或者它可以设置保护标志来阻止下一票第二节和第三节的实际内容是执行，等等。是的。我猜他在问“我的代码完全符合我的要求。这是个坏主意吗？”但你是对的。它可能并没有完全按照他想要的去做。+1他从来没有明确说过他无论如何都想达到第2部分。这里的
//用io异常做点什么
部分可能是
抛出新的WhateverException（）
，例如，在这种情况下，多个catch块就可以很好地完成任务，而且更加清晰。这就是我在回答中试图说明的要点：只有当他真正利用了它允许他做更多事情的事实时，才使用他的方法。否则，只使用“较弱的”（因此更容易理解）多个catch块的标准用法。