I have some trouble with the exception handling im MVC pattern. As I understand (after the reading the Max's book) the controller wraps all exception in the GUIException and transfer it to the view and view shows the Error message to the user.
But the problem that I have, it is my MVC design and exception handling with it. My MVC is: The initialisation of the Model and View occurs in the Controller. The View implements the ModelListener that notifies the view if the model is changed. There are some listener in the Controller that will be added to the view, in order to notify the controller that the e.g. button was pressed. After the controller is notified that the button was pressed, it calls the method of the model And model makes the database calls.
This works very nice, but the problem is the exception handling in it. For example, if some exception occurs in the Model (It communicates with the database), the model throws it to the controller and controller wraps the exception in the GUI exception. It works also nice. But now I am get stuck in how to notify the view that some exception is thrown in the GUI. Two possibilities that I see, one is to define a listener that notified the view that the exception occurs in the controller. After the exception occurs in the controller it notifies the view and the view shows the exception. The second one is to define the public method in the view that will be called by the controller if the exception occurs in it and this method shows the error message to the user.
But I am not sure what is correct and makes more sense. Maybe there is another possibility to handle with this problem. Could you help me to solve this problem? Thanks a lot!!!
I recently had the same problem as you have now, and I guess I will have it again when I start working on my URLyBird assignment.
I solved it like this: The Exceptions caught by the Controller are delegated to the View by method of the sort "view.showErrorMessage(String message, String title)".
The problem with this approach is, however, that there is strong coupling between the Controller and the View because the Controller must know about the View (i.e. contain a reference to it) in order to call this method. This strong coupling makes it hard to change the View and reuse the Controller. Luckily, the solution is quite simple: I made the View implement an interface called ErrorMessageDisplayer declaring the showErrorMessage(...) method and let the Controller contain a reference to the interface only. Therefore, the coupling is reduced to the Controller having to know the ErrorMessageDisplayer interface only.
I do not know what classic MVC architecture you guys are following. I use my own version of MVC with Swing.
* V listens all changes from M, and knows how to access data from M. But not everything about M. * M has no idea who are listeners. * C knows both V and M very well, contains most of rules.
In Swing, V usually sets data back to M which I do not like. Sometimes I use a Application M that separates from Swing M. Or M notifies listeners when V tries to update it, and C in this case will be a listener to those notifications and apply business rules to the change and update M with other proper methods.