Exception translation for public API

[hhoang]

I am design an application library that make use of Spring MVC, Spring, and Hibernate. The ADMIN SECTION of the application has similar architecture to Appfuse (i.e. JSP -> Controller -> Service -> DAO). The PUBLIC SECTION of the application has the architecture similar to as WEB SERVICES OR REMOTE -> SERVICE -> DAO. Here are my questions:

1. What is the best way to handle the Spring exception instead of letting propagate to the calling code.

2. Should I handle the Spring translated exceptions at my DAO or at the SERVICE implementation and rethrow my Custom exception? If I handle at the SERVICE layer, I need to rewrite a little bit if I decided to use JDBC instead of Hibernate in the future.

3. How do I prevent people from accessing my SERVICE and DAO Implementation if somehow they have access to it. Can the package private do the job? It's similar to the internal in .NET?

4. Should I validate the parameters at both the SERVICE and DAO?

Thank you very much
Hai
[/list]

[joe.witt]

These answers are just my opinion...

When reading these keep in mind I like to think of a web application as two applications though I doubt they are often developed as such. I very much like to keep the business tier and persistence tier as a single application. This is the API of some domain. Then, the web-tier is treated as another application that is a client to other application.

With this in mind, I don't like the idea of my web-tier having to know about Spring's dataaccess exception hierarchy.

1. What is the best way to handle the Spring exception instead of letting propagate to the calling code.

2. Should I handle the Spring translated exceptions at my DAO or at the SERVICE implementation and rethrow my Custom exception? If I handle at the SERVICE layer, I need to rewrite a little bit if I decided to use JDBC instead of Hibernate in the future.

Based on what I said above I like the idea of having throws advice wrap all calls to the service layer. The throws advice is ExceptionTranslationAdvice and it simply converts Spring's data access exceptions to exceptions from my hierarchy. This sounds like it could require a lot of translation. I'm sure it would in some applications but I've not seen it being an issue.

This means a call flows as follows:

web tier -> service proxy (with exceptiontransaltoradvice) -> transactionalproxy -> service target -> dao target

I declare the exceptions in the javadocs for the service tier even though the implementation wouldn't actually throw them. Technically, they don't get thrown as that type until the translator gets a hold of them.

The key point is I try to avoid the client depending on Spring as well as my service tier. My DAOs are another story

4. Should I validate the parameters at both the SERVICE and DAO?

I think so. It does require additional code but it is much more expressive. If you simply let NullPointerException's occur it can make testing for the layer above more difficult. If you throw IllegalArgumentExceptions that seems much more descriptive. Further, be sure to document this fact in your javadocs for the interface. If a parameter cannot be null make sure the javadoc says so in the throws IllegalArgumentException area.