Как Вы обрабатываете ошибки в своих ресурсах?

Question

[bit_rainbow]

Вот типичный код ресурса (JAR-RS) в проекте:

@Path("authenticate")
@POST
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public Response authenticate(Credentials credentials) {
  try{
     // some logic
  } catch (Exception1 e) { 
            //   etc  LOGGER.error(e);
            //   return Response.status(Status.UN_AUTHORIZED).build();
   } catch (Exception2 e) { 
            //   etc  LOGGER.error(e);
            //   return Response.status(Status.CAN_NOT_CREATE_TOKEN).build();
   }  catch (Exception3 e) { 
         //   etc  LOGGER.error(e);
         //   return Response.status(Status.SOME_OTHER_ERROR).build();
   }

  
  // return good stuff
}

Код рабочий, но не красивый. Погуглил как сократить количество catch без ущерба - не нашел, порылся в книге по ресту, тоже не нашел. Может кто уже сталикивался с таким может поделиться опытом? Хочу уменшить количество catch без ущерба, потому что в не которых местах есть по 10 catch'ей.

Более менее полезная находка

Answer 1

[pavel null]

1. Ловить ошибку надо в том случае, если вы ее можете обработать. Иначе выкидывайте из метода
2. В java 7 catch можно объединять catch(NullPointerException | ClassNotFindException)
3. Берите базовый класс ошибки, чтобы ловить все catch(Exception)
Такое кол-во catch нормально, особенно когда с http работают.

Answer 2

[DigitalSmile]

Если используете Jersey, то можно вот так https://jersey.java.net/documentation/latest/repre...
Если нет, советую попробовать :)

Answer 3

[Виктор Гогильчин]

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

public static Status getStatus(Exception e) {
        if (e.getClass.equals(MyCoolUnautorisedException.class)) {
           return Status.UN_AUTHORIZED;
        }
        // More Exception handlers
     return null; //If something gone wrong
     }
  //Main code
    try {
       // some logic
    } catch (Exception e) { 
              //   etc  LOGGER.error(e);
              return Response.status(SomeStatusHandler.getStatus(e)).build();
    } finally {
        //Here we go!
    }

Comments

[Viktor Koltcov]

Не обрабатывать исключения а посылать их выше, пусть клиент разбирается с ними
public Response authenticate(Credentials credentials) throws Exception1, Exception2, Exception3 ...

это будет плохой идей? Если да то почему?

[Виктор Гогильчин]

Виктор Кольцов: Тут я вижу что обработка исключений должна быть (поведение зависит от полученного исключения).
А вообще 10 ексепшенов это плохая идея, и сигнализирует о недоработке на ранних стадиях проекта. И если клиенту отдавать - то проще отдать один кастомный Exception в который завернуть (в cause) порождающий. Это будет правильней.

[bit_rainbow]

Виктор Гогильчин: "то проще отдать один кастомный Exception в который завернуть (в cause) порождающий. Это будет правильней" а можете пожалуйста пример привести, кода?

[Виктор Гогильчин]

bit_rainbow: pastebin.com/hCDbMHKi Пожалуйста. :)

Answer 4

[Igor Kalashnikov]

Еще "экзотический" вариант, можно сделать мапу
Exception => Status
ну или более дженерик, типа Exception => Handler
и все кетчи свернуть в простой вызов мапы. Как-то так.

С мапой удобно если у вас много типичных хендлеров.

Answer 5

[Y V]

Большинство рест фреймворков предоставляют возможность писать кастомные ExceptionMapper-ы.