CODEWITHSUNDEEP
javaexceptionmodel-view-controller
cmtjk
cmtjk

Reputation: 359

Exception wrapping in MVC

I'm trying to figure out a valid exception handling approach for a MVC application in Java. In my programming class I learned to write an extra exception for all my classes (right side of diagram) but this gets exhausting in larger applications because you end with a lot of different exception classes and try-catch statements everywhere (which violates the 'throw early, catch late' principle in my opinion) so I tried to apply this approach to my application.

My question is whether the solution shown below (left part of the diagram) is a valid approach or if there are any obstacles I could run in later? Is it even endorsed to wrap occurring exceptions on lower level of the model and hand it over to the controller unchanged or shall all occurring exceptions caught in the top layer of the model only?

I found little information about this so I hope to you can give me some opinions and most important some criticism on this. Thank you in advance!

Exception handling approach for MVC with wrapper class

UPDATE 1: The Model class here consists mostly of

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);
    }

    //...

}

So it holds some data structures but is mostly calling methods of 'service' classes(?) like the FileReader, the Analyzer or Parser. These classes all throw Exceptions like IOException etc. and the controller should know about the important one where I want the user to be informed.

And in my opinion the actual Model class (which doesn't really process data) must not know about exceptions that occur in the 'service' classes. It should just hand them over to the controller who is able to handle them and decide what to do.

And therefore my idea was to already wrap occurring exceptions so the Model class here doesn't have to worry about it.

Upvotes: 1

Views: 228

Answers (1)

Koos Gadellaa
Koos Gadellaa

Reputation: 1254

What I'm missing here are services. Usually when you have a thin model, your services are doing the heavy lifting. However, when you have a thick model, it is possible to do it without services... somewhat.

Nonetheless, your question is regarding exeptions. First off, you're talking Java here, so are they Checked exceptions, or not? Most exceptions should probably be unchecked exceptions, if you think the user of the function cannot reasonably be expected to handle them. You do not want to burden the user of your object with all sorts of edge cases which he cannot take appropriate action on.

Keeping that in mind, it leaves a lot of runtimexceptions. Your controller needs to decide what to do when certain runtimexceptions occur. It might simply show a different error page, or maybe know a little bit from the exception. It is fine for your controller to have an exceptionhandler in there.

As for wrapping exceptions, that should probably only be done when you have an actually layered application. For example, if you have a view layer, a business layer, and a persistence layer (in that order), your persistence layer should only provide its own exceptions. Any underlying technology should be shielded (although if its an exception that cannot be handled at all it might be fine to let it leak through). Similarly for your business layer, it should definitely not show persistence-layer exceptions to the view layer.

Depending on what you expect or want, it could be that your persistence layer has a catch RuntimeException(e) {throw new PersistanceRuntimeException(e);} like structure, although really, you can probably not expect any user to handle such an exception succesfully, so it might be okay to let that one leak through (and let it be handled in your controller's catch RuntimeException(e) {showErrorPage();})

Upvotes: 1

Related Questions