Как записывать журналы сбоев в Java
Я работаю над кроссплатформенным приложением на Java, которое в настоящее время хорошо работает в Windows, Linux и MacOS X. Я пытаюсь разработать хороший способ обнаружения (и обработки) «сбоев». Есть ли простой кроссплатформенный способ обнаружить «сбои» в Java и предпринять какие-либо действия в ответ?
Я думаю, что под «сбоями» я подразумеваю неперехваченные исключения. Однако код действительно использует некоторый JNI, поэтому было бы неплохо иметь возможность отлавливать сбои из-за плохого кода JNI, но у меня есть ощущение, что это специфично для JVM.
Ответы 3
Для обработки неперехваченных исключений вы можете предоставить новую группу ThreadGroup, которая обеспечивает реализацию ThreadGroup.uncaughtException (...). Затем вы можете перехватить любые неперехваченные исключения и обработать их соответствующим образом (например, отправить домой журнал сбоев).
Я не могу помочь вам на фронте JNI, вероятно, есть способ использовать исполняемый файл собственной оболочки перед вызовом JVM, но этот исполняемый файл должен знать обо всех возможных JVM, которые он может вызывать, и о том, как происходит сбой индикатора и где размещаются журналы сбоев и т.д.
Не уверен, что это то, что вам нужно, но вы также можете определить, возникло ли исключение из вашего собственного кода. См. http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/functions.html#wp5234 для получения дополнительной информации.
Для простой комплексной обработки вы можете использовать следующий статический метод в Нить. Из Javadoc:
static void setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh)
Set the default handler invoked when a thread abruptly terminates due to an uncaught exception, and no other handler has been defined for that thread.
Это очень широкий способ работы с ошибками или непроверенными исключениями, которые не могут быть обнаружены где-либо еще.
Примечание: Лучше, если код может перехватывать, регистрировать и / или восстанавливать исключения ближе к источнику проблемы. Я бы зарезервировал такую обобщенную обработку сбоев для полностью неустранимых ситуаций (т.е. подклассов java.lang.Error). Старайтесь избегать возможности того, что RuntimeException когда-либо станет полностью неперехваченным, поскольку это может быть возможно - и предпочтительно - для программного обеспечения выжить в этом случае.
Это полезно знать, поскольку я вызываю Java-код из нативного кода, поэтому он добавит точек, где я могу обрабатывать неожиданные исключения / сбои. Похоже, мне придется разбросать код с помощью нескольких проверок сбоев, используя такой код.