В настоящее время (4 квартал 2017 года) в Maven Central имеется javax.persistence-api
.
javax.persistence
javax.persistence-api
2.2
Код поддерживается в этом github репо .
Соглашение 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);
}
}
}
Я инициализирую прослушиватели событий с реализацией этого, которая обрабатывает сбой любым способом, который имеет смысл в этой точке приложения. Может появиться диалоговое окно,
Если с этим ничего нельзя поделать, вам следует войти в систему и отправить сообщение пользователю. Если что-то пойдет не так, что может повредить данные или дать неправильные результаты, если вы не сможете восстановить, вам следует закрыть приложение.
The usual approach is to ignore the issue. Listeners should not throw unchecked exceptions.
A better approach would be to catch and log RuntimeException
s. These generally indicate a programming error. If a widget on the screen throw an NPE, then there is no reason why the rest of the window should not finish painting. The user can then save their data and restart or otherwise work around the issue. In the case of Error
s it generally means that there is a serious situation, such as OutOfMemeory
and catching will just result in thrashing. Nobody bothers doing this.