How to create a singleton using enum if initializing the object involves checked exception handling

Question

EDIT

Please note my question is more to understand if there is any best practice around it. The problem I am describing can be tackled many way, in fact I am handling it by throwing Runtime Exception. But is it the best practice? or should we fall back to more conventional ways of Singleton creation using a static method and decoupling exception from object creation

I am using enum to instantiate a singleton as prescribed in Effective Java

public enum MailApp { 
INSTANCE;   
private Gmail mailService;

private MailApp() {
    try {
        mailService = GoogleMailAppFactory.getGmailService();
    } catch (IOException e) {
        throw new AssertionError(e);
    }
}

The problem is if I add throws like following

public enum MailApp {

INSTANCE;

 /** Application name. */

private Gmail mailService;

private MailApp() throws IOException {
    mailService = GoogleMailAppFactory.getGmailService();
}

This will not compile saying Unhandled Exception

I have taken a look at How to throw an exception from an enum constructor?

I could not find any conclusive answer. So my question: What are the best practices for this? Is throwing an AssertionError only way forward?

Thanks for your help

Edit

My "MailApp" is only valid if we have a valid email service. In short I dont want to create an empty object. Could you please throw some light why this might be a bad idea and how this should be approached?

Answer 1

You may want to consider rethrowhing ioexception as a RuntimeException.

Answer 2

COMPLEX EXAMPLE:

import android.content.Context;

import java.util.HashMap;
import java.util.Map;


public enum Gender {

     /** non mather */
     NONE(0,R.string.any),

    /** Male */
    MALE(1,R.string.male);

    private final int _rId;
    private final int _id;

    private Context _context;

    public void  setContext(Context context) {
        _context = context;
    }

    private Gender(int id, int rId) {
        _id = id;
        _rId = rId;

        /** get context from setter */
        if(_context==null) {
            throw new NullPointerException("Exception");
        }

    }

    /**
     * @return The string representation of this element in the enumeration.
     */
    public int getResId() {
        return _rId;
    }

    public int getId() {
        return _id;
    }

    public static Gender getById(int id ) {
        return byId.get(id);
    }

    public String getName(){
        return _context.getResources().getString(_rId);
    }

    @Override
    public String toString(){
        return getName();
    }

    private static final Map<Integer, Gender> byId = new HashMap<>();
    static {
        for (Gender gender : Gender.values()) {
            if (byId.put(gender.getId(), gender) != null) {
                throw new IllegalArgumentException("duplicate id: " +gender.getId()); 
            }
        }
    }
}

EDIT:

• try implement Singletons by simply make an enum type with one element
• enum singleton guarantee that it's instance will be once per VM.

basicaly

public final class ISingleton {
    public final static ISingleton INSTANCE = new ISingleton(); 
}

Answer 3

I would actually disagree with this approach specifically because of the issue you are dealing with.

I would implement singletons if I have to in the SE environment as follows:

public final class SingletonClass {
    private static SingletonClass INSTANCE;

    public SingletonClass getInstance() {
        return INSTANCE;
    }

    private SingletonClass() throws WhateverException {
       ...
    }
    static {
       try {
           INSTANCE = new SingletonClass();
       } catch (WhateverException e) {
           throw new RuntimeException(e);
       }
    }
}

The reason why I emphasize if I have to is because I try to avoid it in the first place because it is rare I would have only one of something. And with the notion of Dependency Injection using CDI or Picocontainer which works on SE environments as well though CDI has a lot of baggage and a lot more confusing to diagnose compared to Picocontainer.

On an JEE6 environment I would use the @javax.ejb.Singleton annotation. That guarantees that there is only one instance in a clustered deployment without a lot of fuss.

To clarify why the above works:

• The static initializer only gets executed once Are Java static initializers thread safe?
• Unless you're doing something really complicated, you would only have a single class loader to work with on SE.
• enums are Serializable but there's no guarantee that your singleton class would/should be serializable.
• What you are building is a class, not an enum. This is akin to having the constants in interface which is actually noted as a bad idea in the Effective Java book https://softwareengineering.stackexchange.com/questions/49572/is-it-a-bad-practice-to-have-an-interface-to-define-constants
• This also handles RuntimeException and Error such as OutOfMemoryError in a more predictable fashion in that it will automatically wrap the error in ExceptionInInitializerError which makes it more obvious what the error is.