Leon, I have a question about this one: "You don't need to care for exceptions you don't understand (layer-technically, someone who writes an action doesn't care whether its an SQLException or a FileNotFoundException)"
If you say, that it should be easy to switch layers, then persistence layer should not know about SQLException, should it? JDBC persistence sublayer (driver, connection pool, actual SQL statements, etc) should catch SQLException and return something like StoreException or UpdateException to more generic persistence layer. In this case JDBC sublayer can be switched. What I am trying to say, is that each layer that can be potentially substituted, should catch layer-specific exception itself, and rethrow more generic exceptions, instead of throwing layer-specific exception to calling layer. Does it make sense? Michael J. On 10/7/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > Something in the jdbc driver throws an SQLException, like connection > is lost or whatever > The persistence layer catches it, logs it and rethrows a > PersistencePOJOs Exception, like: DB is generally unavailable or > something. > The business layer catches it and rethrows: Persistencelayer is > unavailable (all names are just examples). > This is caught by the action, which then presents it to the user > (which can be done by throwing a presentation-layer exception and > proceeding it with your general error handler) "Sorry, currently we > can't proceed your request, try again later" or whatever. > The good thing about it: > - You don't need to import classes from other layers > - You don't need to care for exceptions you don't understand > (layer-technically, someone who writes an action doesn't care whether > its an SQLException or a FileNotFoundException) > - You can change the implementation of the complete layer without > changes in other layers (like switching from JDBC to JDO or FS, or > like changing from corba to rmi or ejb). > - You still can log at any point (or at all points) and mail and > notification will work even better. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
