where to load grails message when throwing exception in a service -

where should separation of ui message elements if grails service throws exception? should message loaded service , passed controller via exception, or should controller load message based on type of exception thrown? assumes message have parameter values need filled in.

here exception:

class customexception extends runtimeexception {     string message } 

loading message source controller after catching exception:

class myservice {     void dosomething() {         ...         if (somethingbad) {             string value = 'mary smith'             throw new customexception(value)         }         ...     }  }  class mycontroller {     def myservice      void processrequest() {         try {             myservice.dosomething()         }         catch (customexception e) {             flash.error = g.message(code:'user.input.error', args:'[${e.value}]')             render view:'some_gsp'         }         ...     }  } 

loading error message source in service controller pulls message string exception:

class myservice {     def messagesource     void dosomething() {         ...         if (somethingbad) {             string value = 'mary smith'             throw new customexception(messagesource.getmessage('thread.inactive.user', [value]))         }         ...     } } class mycontroller {     def myservice      void processrequest() {         try {             myservice.dosomething()         }         catch (customexception e) {             flash.error = e.message             render view:'some_gsp'         }         ...     } } 

frankly speaking, neither of 2 places need translations. :)

separation of concern
controller should worry http methods , delegation.
services should take care of transactions , underlying business logic.

declarative error handling
2.0.* , above, grails provides sweet spot handling errors. guess what? declarative error handling

all exception related code moves separate controller (in house) handled properly, keeping business controllers , services clean , abstracted boiler plate codes.

for grails 2.3.*, added feature handle exception in controller of boiler plate (try catch stuff) abstracted controller implementation.

conclusion
if using v2.0.* , above controllers like:

class mycontroller {     def myservice      def processrequest() {         myservice.dosomething()         ...     }  }  //url mapping static mappings = {    "500"(controller: "errors", action: "customexception",          exception: customexception) }  //error controller class errorscontroller {     def customexception() {         def exception = request.exception         // perform desired processing handle exception     } } 

you can move logic of error handling separate plugin if required in order handle variety of errors/exception , unhappy paths. becomes elegant separate concern.

if using v2.3.* controller like:

class mycontroller {     def myservice      def processrequest() {         myservice.dosomething()         ...     }      def handlecustomexception(customexception e) {         //move translation src/groovy/utility if feasible         flash.error = g.message(code:'user.input.error', args:'[${e.value}]')         render view:'some_gsp'     }  } 

in case no handling required services well, need throe exception.

i suppose more input various sources if around , interested use pattern.