Hi Alex (the name you used at signature),

Thanks for the really elaborate insight into the problem. I very much agree with everything you said...I definatelly should have been more verbose when putting up my question

From the 3 different type of exceptions you are describing (BL checked, unchecked and the lightweight PL exceptions), my question was concerning the checked exceptions. As you mention, one way of addressing the issue would be 'collocating' the PL and BL layers - with one really major 'however' - this type of architecture would introduce very tight coupling between the PL and BL as well as it would require the BL to make certain assumptions about the PL. Unfortunately, this wouldn't be a very feasible way in my case, because I have to keep my PL more flexible - both technology-wise (sometimes it's spring sometimes Struts, sometimes Tapestry, etc.) as well as supporting different sub-types of 'web' clients. That makes my BL really a not trusting type

Also, this coupled way would make the testing of BL more complicated, as usually I start with the test case for all sorts of unsuccessful and successful paths. Only after I am done with that I move to presentation layer (which is possibly handled by somebody else on the team).

I was quite surprised not to find much discussion / examples on this type of validation which raised some doubts that maybe there's a better way to handle it in Spring (just like many other things that have really useful 'hooks' for many kinds of common situations).

Nevertheless, the mechanics of my existing validation are very similar to that of Spring (just implement a Validation interface, etc.) so since they look so similar I thought of possibly merging them into one...which is where the problem with 'more elegant' propagation cropped up.


Peter