Поймать исключения из спящего режима с помощью обработчика ошибок?

Question

Я ловлю все исключения в: java.lang.Throwable /page.xhtml java.lang.Error /page.xhtml

Но что, если я получу, например, спящий режим ex: org.hibernate.exception.ConstraintViolationException

Должен ли я определять страницы ошибок для КАЖДОГО, возможно, возникающего исключения? Разве я не могу просто сказать «поймать каждое исключение»?

Обновление

Перенаправление на 404 работ. Но на броском нет!

<servlet>
    <servlet-name>Faces Servlet</servlet-name>
    <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>Faces Servlet</servlet-name>
    <url-pattern>*.jsf</url-pattern>
    <url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
<error-page>
    <exception-type>java.lang.Throwable</exception-type>
    <location>/error.xhtml</location>
</error-page>
<error-page>
    <error-code>404</error-code>
    <location>/error.xhtml</location>
</error-page>

Answer 1

Существует лучший способ обработки исключений в JSF - с помощью пользовательского обработчика исключений, который можно установить в вашем faces-config.xml:

<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
              version="2.0">
  <factory>
    <exception-handler-factory>com.mycompany.CustomExceptionHandlerFactory</exception-handler-factory>
  </factory>
</faces-config>

В этом случае вы можете проверить исключение, его причину и выполнитьлюбые действия, которые вы хотите, так как вы всегда будете иметь под рукой FacesContext.Ниже приведен пример работы с раздражающими ViewExpiredException:

Фабрика:

public class CustomExceptionHandlerFactory extends ExceptionHandlerFactory {
  private ExceptionHandlerFactory parent;

  public CustomExceptionHandlerFactory(ExceptionHandlerFactory parent) {
    this.parent = parent;
  }

  @Override
  public ExceptionHandler getExceptionHandler() {
    return new CustomExceptionHandler(parent.getExceptionHandler());
  }
}

Обработчик:

public class CustomExceptionHandler extends ExceptionHandlerWrapper {
  private ExceptionHandler wrapped;

  public CustomExceptionHandler(ExceptionHandler wrapped) {
    this.wrapped = wrapped;
  }

  @Override
  public ExceptionHandler getWrapped() {
    return wrapped;
  }

  @Override
  public void handle() throws FacesException {
    Iterator<ExceptionQueuedEvent> i = getUnhandledExceptionQueuedEvents().iterator();
    while (i.hasNext()) {
      ExceptionQueuedEvent event = i.next();
      ExceptionQueuedEventContext context = (ExceptionQueuedEventContext) event.getSource();
      Throwable t = context.getException();
      FacesContext fc = context.getContext();
      boolean exceptionHandled = handleException(t, fc);
      if(exceptionHandled) i.remove(); // remove from queue
    }
    getWrapped().handle(); // let wrapped ExceptionHandler do the rest
  }

  private boolean handleException(Throwable t, FacesContext fc) {
    if (t instanceof ViewExpiredException) {
      try {
        fc.getExternalContext().redirect("/expired/url/");
        return true;
      } catch (IOException e) {
        throw new FacesException(e);
      }
    } else return false;
  }
}

Answer 2

Класс java.lang.Throwable является наименее распространенным предком всех классов в иерархии классов исключений Java. Все классы исключений и ошибок расширяются прямо или косвенно Throwable.

Если у вас есть страница ошибки для Throwable, то любое исключение, у которого нет более конкретной страницы ошибки, закончится там.

Таким образом, ответ на ваш вопрос "Нет". Вы можете обрабатывать исключения Hibernate отдельно, если хотите (с любой степенью детализации, которую вы считаете подходящей), но вам это не нужно.

---

UPDATE

Существует ряд возможных причин, по которым исключения не выдают страницы ошибок. Например, они могут возникать во время обработки перенаправления или могут быть перехвачены фильтром. Или они могут быть выброшены после заголовка ответа; например если исключение происходит во время форматирования HTML ответа.

(Одним из важных признаков будет то, получаете ли вы какую-либо страницу с ошибкой вообще при возникновении исключения. Если вы получаете страницу с ошибкой '500', то что-то происходит Если нет, то вы, вероятно, находитесь в одной из тех ситуаций, которые препятствуют генерации страницы с ошибкой.)

В любом случае, вот что говорит спецификация Servlet (версия 3.0). Прочитайте это внимательно.

---

10.9.2 Страницы с ошибками

Чтобы позволить разработчикам настраивать внешний вид содержимого, возвращаемого веб-клиенту когда сервлет генерирует ошибку, дескриптор развертывания определяет список ошибок описания страниц. Синтаксис позволяет конфигурации ресурсов возвращаться контейнер, когда сервлет или фильтр вызывает sendError в ответе для конкретные коды состояния, или если сервлет генерирует исключение или ошибку, которая распространяется в контейнер.

Если в ответе вызывается метод sendError, контейнер обращается к списку объявления страницы ошибок для веб-приложения, которые используют синтаксис кода состояния и пытается матч. Если есть совпадение, контейнер возвращает ресурс, как указано у входа в местоположение.

Сервлет или фильтр могут выдавать следующие исключения во время обработки запрос:

• исключения или ошибки во время выполнения
• ServletException или его подклассы
• IO Исключения или их подклассы

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

Если объявление страницы ошибки, содержащее тип исключения, не подходит с использованием соответствие иерархии, и выбрасываемое исключение - ServletException или подкласс из этого контейнер извлекает упакованное исключение, как определено ServletException.getRootCause метод. Второй проход сделан по ошибке объявления страницы, снова попытка сопоставления с объявлениями страницы ошибки, но вместо этого используется упакованное исключение.

Объявления страницы ошибок с использованием элемента исключения-типа в развертывании дескриптор должен быть уникальным вплоть до имени класса типа исключения. Так же, Объявления страницы ошибок с использованием элемента status-code должны быть уникальными в дескриптор развертывания до кода состояния.

Описанный механизм страниц с ошибками не вмешивается при возникновении ошибок, когда вызывается с использованием метода RequestDispatcher или filter.doFilter. Таким образом, Фильтр или сервлет с помощью RequestDispatcher имеет возможность обрабатывать ошибки генерироваться.

Если сервлет генерирует ошибку, которая не обрабатывается механизмом страницы ошибок какКак описано выше, контейнер должен обеспечить отправку ответа со статусом 500. Сервлет и контейнер по умолчанию будут использовать метод sendError для отправки 4xx и 5xx ответов о состоянии, так что механизм ошибок может быть вызван. По умолчанию сервлет и контейнер будут использовать метод setStatus для ответов 2xx и 3xx и не будет вызывать механизм страниц с ошибками.

Если приложение использует асинхронные операции, как описано в разделе 2.3.3.3, «Асинхронная обработка» на стр. 2-10, приложение несет ответственность за обрабатывать все ошибки в потоках, созданных приложением. Контейнер МОЖЕТ позаботиться о ошибки из потока, выпущенные через AsyncContext.start. Для обработки ошибок, которые происходят во время AsyncContext.dispatch, см. раздел n «Любые ошибки или исключения ДОЛЖНЫ быть обнаружены во время выполнения методов диспетчеризации и контейнер обрабатывается следующим образом: »на стр. 2-16