ansaurus

Question

How To Know The Cause Of A Validation Error

Answer 1

A:

I would think that the ValidationException has a reference to the object that failed validation? If it does then check the errors property for the list of errors.

If not you will need to catch it and then check theChild.errors for the errors.

leebutts 2009-10-29 02:41:24

Thanks for your reply. It got me to do a better search.It looks like this will be taken care of in 1.2RC1http://jira.codehaus.org/browse/GRAILS-5146

Brad Rhoads 2009-10-29 03:11:45

Answer 2

A:

Granted, the save(failOnError:true) approach currently yields too little information about what validation caused the problem. (Do you really want to parse exception messages in the controller anyway?) However, there are multiple alternatives you might consider to deal with two different issues, transaction rollback and communicating validation error information.

One alternative is to avoid the persistence of the data altogether. First, call theChild.validate() to see if theChild can be saved. If no validations fail, validate() returns true, so call theChild.save(). If validation errors occur, they will be recorded in the errors object on theChild. The newly created child returned to the calling controller can then be inspected for errors or simply displayed to the user in the view.

Another alternative is to not use declarative transactions; i.e. set static transactional = false on the service. Then, your code could manage the transaction itself; something like this:

Child.withTransaction { txStatus ->
   try {
     child.save(failOnError:true)
   } catch (ValidationException e) {
     // rollback, but swallow exception, requiring caller to check child for errors
     txStatus.setRollbackOnly()
   }
}

Finally, your question implies you want the controller to do something with the errors information, such as rendering the original page so a user can correct entries. Since theChild is what's validated, returning the child won't work when an exception is being thrown (your own or ValidationException). However, the child will have errors populated during the save() call. Instead of passing in a String and Parent, then instantiating a Child in the service, you should consider instantiating the Child in the caller and passing it in by reference. Then, when the save() fails, the child's errors will be populated, even if the save(failOnError:true) results in a ValidationException. The caller can catch the ValidationException and then pass the child back as part of the model for the view.

Personally, I think the first alternative (call validate() first) or the last (instantiate the child outside the service) is preferable to managing transactions manually. In Grails, the declarative transaction management is all or nothing for the entire service. That is, if you set static transactional = false for the service, you'll have to manually manage all transactions in every method of the service. The KISS principle should be applied here.

MadJack 2009-10-30 06:31:20

ansaurus

tags:

views:

answers:

How To Know The Cause Of A Validation Error

related questions