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

Question

Where should the separation of the UI message elements be if a grails service throws an exception? Should the message get loaded by the service and passed to the controller via the exception, or should the controller load the message based on the type of exception thrown? This assumes the message will have some parameter values that need to be filled in.
Here is an exception:
class CustomException extends RuntimeException {
String message
}
Loading the message source from the controller after catching the 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 from message source in the service where the controller pulls the message string the from the 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'
}
...
}
}

Answer 1

Frankly speaking, neither of those two places do you need the translations. :)
Separation Of Concern
Controller should only worry about HTTP methods and its delegation.
Services should take care of transactions and underlying business logic.
Declarative Error Handling
For 2.0.* and above, Grails provides you a sweet spot for handling errors. Guess what? Declarative Error Handling
All exception related code moves to a separate controller (in house) where they are handled properly, keeping your business controllers and services clean and abstracted from boiler plate codes.
For Grails 2.3.*, an added feature was to handle exception in the controller itself but most of the boiler plate (try catch stuff) is abstracted from the controller implementation.
Conclusion
If you are using v2.0.* and above then your controllers would look something 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 to handle the exception
}
}
You can move the logic of error handling to a separate plugin if required in order to handle variety of errors/exception and unhappy paths. It becomes elegant to separate this concern.
If you are using v2.3.* then your controller would look something like:
class MyController {
def myService
def processRequest() {
myService.doSomething()
...
}
def handleCustomException(CustomException e) {
//Move this translation to src/groovy/utility if feasible
flash.error = g.message(code:'user.input.error', args:'[${e.value}]')
render view:'some_gsp'
}
}
In this case no handling required from services as well, you just need to throe that exception.
I suppose you would get more input from various sources as well if you look around and are interested to use this pattern.