When I throw an exception from the package in which I handle the database, in the package in which I handle the UI, should I throw the same exception or create another?
The UI package should know the exceptions of the package which I handle the database?
We as programmers want to write quality code that solves problems. Unfortunately, exceptions come as side effects of our code. No one likes side effects, so we soon find our own ways to get around them. I have seen some smart programmers deal with exceptions the following way:
public void consumeAndForgetAllExceptions(){
try {
...some code that throws exceptions
} catch (Exception ex){
ex.printStacktrace();
}
}
What is wrong with the code above?
Once an exception is thrown, normal program execution is suspended and control is transferred to the catch block. The catch block catches the exception and just suppresses it. Execution of the program continues after the catch block, as if nothing had happened.
How about the following?
public void someMethod() throws Exception{
}
This method is a blank one; it does not have any code in it. How can a blank method throw exceptions? Java does not stop you from doing this. Recently, I came across similar code where the method was declared to throw exceptions, but there was no code that actually generated that exception. When I asked the programmer, he replied "I know, it is corrupting the API, but I am used to doing it and it works."
Please visit here for more details.
To keep your layers tightly coupled, I recommend to abstract your Exceptions (if there isn't a fitting standard exception). With abstract I mean that you could wrap database-dependent exceptions like SQLException into a PersistenceException or sth. like that. This way you can easily change your layers without having to worry about changing code of the layers above.
You should then only catch and handle the exception if you can handle them, e.g. propagate it to the user in you GUI. Otherwise you should throw them to the next caller, until it is handled on a higher level.
You should avoid recreating new exceptions on their way up, that wouldn't add any information in most cases.
You should throw an Exception that makes sense. More importantly you should not throw an exception that doesn't. Exceptions represent error states that you cannot easily recover from, meaning that if you have code to handle things like missing files, it should not throw an exception. You should only throw an exception when something unexpected happens.
As exceptions propagate up through your stack, they should be diversified, depending on what part of the code they where caught in.
For instance your persistence framework may throw an SqlException, your DAO Layer may re-throwthis as an IllegalArgumentExection, or ObjectNotFoundEception, your Service Layer may throw a MalformedRequestException, an AccessDeniedException or a DeviceNotEnrolledException. Lastly your UI may display this to the user in any number of meaningful ways.
I recommend putting the exceptions where it relates the most. You should have different exceptions that handle the code in different types of situations. The UI is going to have different types of exceptions it should handle than the database.
Use pre-defined exceptions where it makes sense, you could also make your own exceptions and put them in both packages if need be.
Design it so that the code can be handled in a way where the catch statement is easy to logically locate and the catch statement handles the code and can do some sort of recovery after being passed up the hierarchy.
The type of situation we are concerned with the most are checked exceptions. These are problems that we can anticipate and catch and try to make a recovery. Make sure you aren't using too many of these! They are costly to resources!
