2

My specific problem is how to handle internationalization of specific messages from an architecture layer that is not the view layer(e.g service layer).

I've created an architecture based on technology to be used (e.g. jsf, primefaces, spring, postgres and mybatis). So to avoid rewriting code i've defined a project to be a jar (with maven) that has all generic (abstract) classes that one should implement (based on interfaces). Something like (to keep it short I will focus in one functionality and I will not add the dao classes)

com.arch
 |_ service
 |   |_ GenericService.java
 |   |_ AbstractGenericServiceImpl.java
 |   |_ GenericServiceException.java
 |_ domain
 |   |_ GenericDomain.java
 |_ view
     |_ AbstractGenericManagedBean.java

With this in a jar file I can create an application that will abstract all the repetitive operations like add, edit, delete, list, etc.

In my AbstractGenericServiceImpl all operations throws GenericServiceException with a message based on the original exception like this:

@Override
public void add(E entity) throws D {
    try {
        getGenericDao().add(entity);
    } catch (DuplicateKeyException ex) {
        throw getNewException("Duplicate registry. Can not add.");
    }
}

This is just one of many exceptions that I catch and throw as my GenericServiceException.

So in my web application I have all necessary structure to handle internationalization as the JSF 2.x specification recommend the i18n package with the properties files whithin e.g. (messages.properties, messages_en.properties, messages_pt_BR.properties and so on.) and it is configured on the faces-config.xml it all works fine FOR MY XHTML files but what about my service files which is decoupled of my web app? How can I change my messages from the getNewException("Duplicate registry. Can not add.") to something like 

getNewException(WebAppChoosedLanguage.getMessage(WebAppMessages.DUPLICATE_REGISTRY))

Is this a good approach or I should let the generic service always throw every exception to be handled by the managed beans that called the service?

I'm asking this because every question that I find about it only speak on the view layer.

Code for the method getNewException:

private D getNewException(String message) {
    try {
        ParameterizedType type = (ParameterizedType) getClass().getGenericSuperclass();
        Class<D> theType = (Class<D>) type.getActualTypeArguments()[2];
        Constructor<D> constructor = theType.getConstructor(String.class);
        return constructor.newInstance(message);
    } catch (NoSuchMethodException | SecurityException 
                 | InstantiationException 
                 | IllegalAccessException 
                 | IllegalArgumentException
                 | InvocationTargetException e) {
        logger.error("Erro ao executar o reflection para exceção. " + e.getMessage());
    }
    return null;
}
Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Jorge Campos
  • 278
  • 3
  • 11

1 Answers1

2

The type of the exception that is thrown should not be specific to the human language domain.

Throw some exception that's named in English, and look up an internationalized string for the exception description.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • That method `getNewException` returns an instance of the exception choosen by the programmer of the web application that should extends my own `GenericServiceException` so in a class created by him they can throw any exception as he wants as long as he follow the contract. What you say is that I should create an specific exception to each one that I catch and then throw it forward so the application (view) can handle the message internationalized. This is the definition of my genericservice interface: `public interface GenericService` – Jorge Campos Apr 15 '15 at 22:28
  • Well, I'm still trying to figure out why you need a Factory Method to get your exception in the first place. The whole point of a factory method is to vary the return type based on a string setting or some similar condition. Internationalization would qualify as such a setting. What I'm saying is to throw a `DuplicateRegistryException`, and either lookup an internationalized description string when you throw it, or simply throw it without a description. Using a factory method to do this seems like overkill. – Robert Harvey Apr 15 '15 at 22:30
  • It is a method to create an instance of the parameterized exception if it is created on the application. My methods on the interface is like: `void add(E entity) throws T;` so in the implementation I can throw forward the exception on the webapp something like `WebAppException extends GenericServiceException` and my abstract service would know what instance of the exception it should throw. Am I wrong with this approach ? +1 for your answer and help anyway! – Jorge Campos Apr 15 '15 at 22:36
  • Why do you need this additional layer of abstraction? What does it add that merely throwing `WebAppException` directly doesn't already provide? `throw new WebAppException(getInternationalizedExceptionString(blah))` – Robert Harvey Apr 15 '15 at 22:38
  • This would work `WebAppException(getInternationalizedExceptionString(blah))` for the exceptions on the web application my problem is with the ones on the abstraction – Jorge Campos Apr 15 '15 at 23:05
  • So the factory method is just an already-existing, necessary evil then? – Robert Harvey Apr 15 '15 at 23:06
  • Yes precisely it – Jorge Campos Apr 15 '15 at 23:07
  • So it comes down to hard-coding an English error message vs. looking up an internationalized one? Which do *you* prefer? – Robert Harvey Apr 15 '15 at 23:08
  • Thats exactly what I want to know! What would be the best approach? I would like the internationalized best – Jorge Campos Apr 15 '15 at 23:15
  • How are you looking up such strings elsewhere? – Robert Harvey Apr 15 '15 at 23:18
  • I'm not. My internationalization is all on the faces (jsf2) layer on the webapplication. I just have a package i18n with messages files in it and the proper configuration on the faces-config.xml. And a LanguageManagedBean to change the Locale – Jorge Campos Apr 15 '15 at 23:21
  • The gurus in [The Whiteboard](http://chat.stackexchange.com/rooms/21/the-whiteboard) seem to think that attempting to look up an internationalized error message while you're already in an error condition is probably not the greatest idea. The consumers of your service layer are almost certainly programmers; perhaps throw an error code, which they can then look up in the documentation in the language of their choice? Note that most programmers know at least *some* English. – Robert Harvey Apr 15 '15 at 23:25
  • I don't really like this approach on my specific problem because you see, there are some predefined errors that is caused by the missusage of the user on the application. The DuplicateKeyException for one happens when a user try to create something that already is in a database so should I give him: "Erro code: 30. Talk to the support" or "Duplicate registry" which tells him exactly what got wrong and him can fix it by himself. That way the programmer would not have to program the exception `getJsfUtil().addMessageError(e.getMessage());` it is sended right to the application xhtml – Jorge Campos Apr 15 '15 at 23:44
  • So look up the error message in the correct language, just like your example. Is this OK? It is if it meets your needs. – Robert Harvey Apr 15 '15 at 23:47
  • Yeah, I will end up doing it. The problem of this approch is that I have to create on the application a class `WebAppMessages` fill it with all error constants and each constant with the value of the property key for the message like: `public static final String DUPLICATE_REGISTRY = "app.duplicateregistry";`. Thanks for you help and attention. I will wait a little longer to see if someone else can adds up something, if not I will accept your answer. Thanks again. Cheers – Jorge Campos Apr 15 '15 at 23:55
  • You could use the exception class name as lookup key, inside your Web layer that is. – Wouter Lievens Apr 21 '15 at 05:22