0

I understand that Spring Validator is widely used, and as an application I'm currently working on already uses Spring, it seems the right way to go when validating class details.

My Service layer is going to be validating objects, using the appropriate implementation of Validator.

The best way of then dealing with these errors, as I can see, is throwing my own exception within the Service layer - so that transactions are rolled back and the exception can be caught and handled by my UI layer.

Question is - why pass this Errors object around at all? As Java deals with exceptions naturally, I'd have thought throwing an appropriate Exception (perhaps with all error details) would be performed?

Relatively new to this, so any input greatly appreciated.

user2482461
  • 236
  • 3
  • 11
  • I think you'll want to check [this other answer](http://stackoverflow.com/questions/12146298/spring-mvc-how-to-perform-validation). No exceptions involved. During validation you mainly check data to ensure/enforce valid inputs, but there shouldn't be any reason to rollback any transaction (since you didn't alter any record in your database). – Fritz Jul 10 '13 at 18:15
  • That is a great resource - but it still says, on method 2, to "do something" and "do something else" within the controller. I'm not using Spring MVC, as I understand it is web based (this is just a rich client application), so this "do something" and "do something else" would be exception throwing (to propagate up the layers to the UI) - right? I'm starting transactions in my service layer, as this seems the most logical place to put them, although I could validate within the layer first, *then* begin the transaction programmatically.. – user2482461 Jul 10 '13 at 18:18
  • Didn't notice the "rich client" part on the title. This is quite a debate, in fact. Some like exceptions, some use them only when you have to define that an unexpected event occured. Validation usually is a check, and thus, some frameworks/practices enforce the use of messagind and data structures like summaries. If you decide to throw an exception you'll still have to resort to some kind of error code or exception hierarchy to be able to define _what_ actually happened. – Fritz Jul 10 '13 at 18:27
  • I agree - The errors object / interface that Spring gives back out of the Validator interface can be added to, it just seems like I'm coupling my Service layer with Spring as well as validation.. So just wanted to confirm whether or not I'm heading along the right track. I'm adding to the errors in the service layer, then eventually throwing this as a ValidationException and dealing with the errors returned in the ErrorsObject within this exception. Does that sound 'right'? – user2482461 Jul 10 '13 at 18:43
  • That's what happens when you use a framework. If you want to use exceptions it's up to you. If you want to "extend" the validation logic by adding exceptions is as valid as not using them at all, as long as you can defend your position. – Fritz Jul 10 '13 at 19:20

0 Answers0