Обработка исключений Java в «событиях»

Question

Я хотел бы получить второе мнение о том, как обрабатывать исключения в «событиях» (ввод с клавиатуры, обновление экрана и т. Д.). В этом случае у меня есть контроль над отправителем события.

Таким образом, модуль настроен на обработку события (он реализует интерфейс слушателя и зарегистрирован для отправителя события):

public void DefaultSet ( CardData oldDefault, CardData newDefault )
{
}

Отправитель события просто:

        for ( Enumeration e = listeners.elements(); e.hasMoreElements(); )
        {
            RetrieverListener thisListener = (RetrieverListener) e.nextElement();
            thisListener.DefaultSet( oldDefault, newDefault );
        }

Так что, если / когда что-то пойдет не так в приемнике:

• Должен ли я попытаться справиться с этим исключением и никогда не отправлять что-либо обратно отправителю? Иногда у слушателей нет «контекста» для правильной обработки ошибки, верно?

• Хмурится ли он тем, что выбрасывает исключение обратно в модуль отправки событий, который обрабатывается задокументированным способом? например Msgstr "Бросок IOException приведет к сбросу ..". Это кажется нестандартным из прочитанных мною javadocs.

• Должен ли я просто регистрировать и игнорировать исключение, когда что-то идет не так, и с этим ничего не поделаешь?

Answer 1

Соглашение Java состоит в том, что методы слушателя не генерируют исключения. Очевидно, что ошибки программирования могут заставить слушателя вызвать исключение RuntimeException, но источник событий не сможет восстановить его, поскольку он оставит объекты программы в каком-то неизвестном, возможно, несовместимом состоянии.

Поэтому слушатель должен перехватить проверенные исключения и либо восстановить их (например, выполнить откат транзакции), либо сообщить о них другому объекту. Я часто использую интерфейс ErrorHandler, который выглядит примерно так:

public interface ErrorHandler {
    public void errorOccurred(String whatIWasTryingToDo, Exception failure);
}

Слушатель событий сообщает свой ErrorHandler об ошибках, которые произошли.

public class SomeClass implements SomeKindOfListener 
    private final ErrorHandler errorHandler;
    ... other fields ...

    public SomeClass(ErrorHandler errorHandler, ... other parameters ... ) {
        this.errorHandler = errorHandler;
        ...
    }

    public void listenerCallback(SomeEvent e) {
        try {
            ... do something that might fail ...
        }
        catch (SomeKindOfException e) {
            errorHandler.errorOccurred("trying to wiggle the widget", e);
        }
    }         
}

Я инициализирую прослушиватели событий реализацией этого, которая обрабатывает сбой любым способом, который имеет смысл в тот момент в приложении. Это может вызвать всплывающее диалоговое окно, показать мигающий значок ошибки в строке состояния, зарегистрировать сообщение аудита или прервать процесс, например.

Answer 2

Когда с этим ничего не поделаешь, вы должны войти в систему и отправить сообщение пользователю. Если что-то пойдет не так, что может повредить данные или дать неверные результаты, если вы не можете восстановить, закройте приложение.

Answer 3

Обычный подход - игнорировать проблему. Слушатели не должны бросать непроверенные исключения.

Лучше всего было бы поймать и записать RuntimeException с. Они обычно указывают на ошибку программирования. Если виджет на экране выбрасывает NPE, то нет причин, по которым остальная часть окна не должна заканчивать рисование. Затем пользователь может сохранить свои данные и перезапустить или иным образом обойти проблему. В случае Error s это обычно означает, что существует серьезная ситуация, такая как OutOfMemeory, и отлов просто приведет к перебоям. Никто не мешает это делать.