Well-designed applications are often designed in tiers. Perhaps you have a data tier, and all of the objects of a similar type in a similar package are dedicated to accessing the database, and returning the result of the operation up to another tier of the application.
The purpose of the tiers is to separate different functions. N-Tier development dictates that you don't mix your user interface code with your workflow code or your data access code. It stands to reason that you do not mix an exception generated in the data tier with client tier code.
But you do need to handle the exception. So it's a predicament. Well, the thing to do is wrap up your SQLException object in an exception object that hangs out with the client tier crowd .
Let's take a look at an example of a custom exception wrapper for doing this very kind of thing.
