Designing General Exception Classes??

[j.gohel]

Hi,

I have a made a application using MVC architecture having servlets & jsp.Till now i was debugging my application's error using LOGGER .But i want to design some general classes for the catching the exceptions through which which I can inform the user about the problem either technical related or business logic related as for some cases i have to write more than one catch block to handle the exception.

My controller ultimately returns a jsp page.

Now in my class methods calls occurs so from the method called i am using boolean value to be returned which returns true if all the things works successfully & false if some error occurs.

Now in that called method some try catch blocks also occurs.But whenever some exception occurs i assign false value to the flag i am using for returning .

But i dont want to do that .

I want to return a page displaying the error message WHICH THE USER CAN UNDERSTAND using the general classes i want to make as mentioned above, through which i can give the user appropriate
message ie what cause the exception or what is the error categorizing it as a SYSTEM ERROR or APPLICATION ERROR.

So please provide me an example regarding the same... or some pseudocode for how to proceed??

Thanks,
Jignesh

[Belisarius]

Here are a couple links on how to setup an ErrorPage with Tomcat -

Link 1
Link 2

What you'd need to do is catch as many possible exceptions at the lowest diagnosable level and then throw a new exception with a plain-language explaination of what occurred. You can then display that error message to the user on the error page.

[j.gohel]

Hi Belisarius,

Originally Posted by Belisarius

What you'd need to do is catch as many possible exceptions at the lowest diagnosable level and then throw a new exception with a plain-language explaination of what occurred.

I didn't understood the thing catching exceptions at lowest diagnosable level.

Jignesh

[Belisarius]

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).