Java MVC中的异常包装

我试图为Java中的MVC应用程序找到一种有效的异常处理方法。在我的编程课上，我学会了为我的所有类（图的右侧）编写一个额外的异常，但在大型应用程序中，这会让人精疲力竭，因为最终会出现许多不同的异常类，并且到处都尝试catch语句（这违反了我认为的“早抛出，晚捕获”原则）所以我试着把这个应用到我的申请中

我的问题是下面所示的解决方案（图的左部分）是否是有效的方法，或者是否有任何障碍我可以在以后运行？是否批准将发生的异常包装在模型的较低级别，并将其未经更改地移交给控制器，或者所有发生的异常仅捕获在模型的顶层

我发现这方面的信息很少，所以我希望你们能给我一些意见，最重要的是一些批评。提前谢谢你

更新1: 这里的

模型

类主要由

public class Model {

    private MyData someData;
    //some more data

    public String parseFile(file) {
        return Parser.parse(file);
    }

    public Result analyzeData(someData) {
        return Analyzer.analyze(someData);
    }

    //...

}

因此，它包含一些数据结构，但主要调用“服务”类（？）的方法，如

文件读取器

、

分析器

或

解析器

。这些类都抛出

异常

如

IOException

等，控制器应该知道我希望通知用户的重要异常

在我看来，实际的

模型

类（实际上并不处理数据）必须不知道“服务”类中发生的异常。它应该把它们交给能够处理它们并决定做什么的控制器

---

因此，我的想法是已经包装发生的异常，这样这里的

模型
类就不必担心它了。
这里我缺少的是服务。通常当你有一个瘦的模型，你的服务是做繁重的工作。但是，当您有一个厚模型时，可以在没有服务的情况下完成它。。。有点

尽管如此，你的问题是关于例外。首先，这里讲的是Java，那么它们是否检查了异常？
如果您认为函数的用户无法合理地处理这些异常，那么大多数异常可能应该是未经检查的异常。您不想让对象的用户承担各种边缘情况的负担，因为用户无法对这些情况采取适当的操作

记住这一点，它会留下很多运行时异常。当某些运行时异常发生时，控制器需要决定要做什么。它可能只是显示一个不同的错误页面，或者可能从异常中了解一点。您的控制器可以在其中包含exceptionhandler

至于包装异常，可能只有当您有一个实际分层的应用程序时才应该这样做。例如，如果您有一个视图层、一个业务层和一个持久性层（按顺序），那么持久性层应该只提供它自己的异常。任何底层技术都应该被屏蔽（尽管如果它是一个根本无法处理的异常，那么让它泄漏出去也可以）。与业务层类似，它绝对不应该显示视图层的持久层异常

根据您的期望或需要，可能是您的持久性层有一个类似于
catch RuntimeException（e）{throw new PersistanceRuntimeException（e）；}
的结构，尽管实际上，您可能无法期望任何用户成功地处理这样的异常，所以让该异常泄漏出去也可以（并让它在控制器的
catch RuntimeException（e）{showErrorPage（）；}
中处理）
首先，谢谢你的回答。我更新了我的问题，不知怎的，我认为我的
模型就像一个层，因为它只保存一些数据并调用底层类的方法。它并不真正处理数据，我想知道向通过模型的控制器转发异常的最佳方式是什么，而不需要像“publ”这样的代码ic字符串getDataFromFile（file）在模型类中抛出IOException、XMLParseException、SomeOtherException{return Parser.parse（file）；}。因此我认为包装器可以做到这一点。您需要问的问题是，对
公共字符串getDataFromFile（file）的函数调用抛出IOException、XMLParseException、SomeOtherException
将允许用户合理地处理
IOException、XMLParseException、SomeOtherException
。可能他不能，因此它们可能应该是RuntimeException。这应该在您的层中处理（因为用户无法正确恢复）然而，您的控制器应该总是正常地发生故障，因此对于这种情况可能会有一个
@ExceptionHandler
。也许它可以区分运行时异常，但这取决于您。