Quote:
|
I didn't understood the thing catching exceptions at lowest diagnosable level.
|
For instance, say you have a login JSP that makes a call to a bean that in turns calls a database connection class. A user gives an incorrect password. The database connection class submits a query using the password and the user name, but returns 0 rows. It's performed it's function - it doesn't know how to do anything other than connect to the database, execute a query and return the results. But at the bean class, you know something is wrong because what should have returned a single row returned nothing. If there had been something wrong with the actual database connection, an Exception should have come from the database connection class, so the only reasonable alternative is that either the user doesn't exist or a bad password was entered. This is the lowest level that you could have diagnosed the problem at (as opposed to having actually diagnosed it at a higher level, say in the JSP). It therefore behooves you to diagnose the problem (invalid login) and throw the Exception at this level.
If you attempt to catch the error at a higher level, there's an increased chance that a series of events can occur that you didn't anticipate. If, for instance, you have multiple points of authentication, but only checked for errors originally in first login JSP you wrote, you will have to duplicate your code and might end up forgetting to do the check somewhere. While it's unlikely in this example, it's more likely in other, more esoteric examples.
Therefore, the earliest you can diagnose an error in any sort of action (login, data entry, transaction, whatever), that is where you should throw the Exception, and let it traverse up the stack (which is the long line of methods you get when you encounter a runtime error) until it reaches the point you want to deal with it - which I assume is the Tomcat error page (which is described in the links I provided).