Question

当我从处理数据库的包中抛出异常时，在我处理UI的包中，我应该抛出相同的异常还是创建另一个异常？

UI包应该知道我处理数据库的包的例外吗？

Answer 1

我们作为程序员想要编写解决问题的高质量代码。不幸的是，例外是我们代码的副作用。没有人喜欢副作用，所以我们很快找到了解决它们的方法。我看到一些聪明的程序员通过以下方式处理异常：

public void consumeAndForgetAllExceptions(){
    try {
        ...some code that throws exceptions
    } catch (Exception ex){
        ex.printStacktrace();
    }
}

上面的代码出了什么问题？

抛出异常后，将暂停正常的程序执行，并将控制权转移到catch块。 catch块捕获异常并且只是抑制它。在catch块之后继续执行程序，就好像什么都没发生一样。

以下情况如何？

 public void someMethod() throws Exception{
 }

这种方法是空白的;它没有任何代码。一个空方法如何抛出异常？ Java并不会阻止你这样做。最近，我遇到了类似的代码，其中声明了方法抛出异常，但没有实际生成该异常的代码。当我问程序员时，他回答说“我知道，它正在破坏API，但我已经习惯了这样做而且它有效。”

请访问 here 了解详情。

Answer 2

为了保持你的图层紧密耦合，我建议摘要你的Exception（如果没有合适的标准例外）。使用抽象我的意思是你可以将像SQLException这样的依赖于数据库的异常包装成PersistenceException或者......像那样。这样，您可以轻松更改图层，而无需担心更改上面图层的代码。然后，您应该只捕获并处理异常，如果您可以处理它们，例如将它传播给GUI中的用户。否则你应该把它们扔到下一个调用者，直到它在更高级别处理。你应该避免在他们的路上重新创建新的例外，在大多数情况下都不会添加任何信息。

Answer 3

你应该抛出一个有意义的异常。更重要的是，你不应该抛出没有的异常。异常表示您无法轻松恢复的错误状态，这意味着如果您有代码来处理丢失文件之类的内容，则不应抛出异常。只有在发生意外情况时才应该抛出异常。

随着异常在堆栈中传播，它们应该多样化，具体取决于它们所处的代码部分。

例如，您的持久性框架可能抛出SqlException，您的DAO层可能会将其作为IllegalArgumentExection或ObjectNotFoundEception重新抛出，您的服务层可能会抛出MalformedRequestException，AccessDeniedException或DeviceNotEnrolledException。最后，您的UI可以以任意数量的方式向用户显示此内容。

Answer 4

我建议将例外情况放在最相关的地方。您应该有不同的异常来处理不同类型情况下的代码。 UI将比数据库具有不同类型的异常。

在有意义的情况下使用预定义的异常，如果需要，您也可以制作自己的异常并将它们放在两个包中。

设计它以便可以以一种方式处理代码，其中catch语句易于逻辑定位，catch语句处理代码，并且可以在传递给层次结构后进行某种恢复。

我们最关心的情况类型是经过检查的例外情况。这些是我们可以预见并捕获并尝试恢复的问题。确保你没有使用太多这些！资源成本高昂！

处理Java应用程序中的异常

4 个答案: