Сервис, имеющий доступ к базе просает javax.persistence.EntityNotFound exception, при попытке найти запись по ID
Это JPA exception, хотелось бы его спрятать, чтобы клиент ничего не знал о нем.
По идее, допустум сервис — фасад для клиента (веб формы, спринг формы, servleta, не важно — facade для web слоя), должен сделать try/catch, и бросить, к примеру
RuntimeException("Could not find any record", jpaException)
Но получается, что желание оградить конечного клиента — от знания, что он имеет дела с jpa технологией или с зависимостью от jpa, приводит к усложнению обработки в facade.
Есть какие нибудь идеи, мысли на этот счет?
В идеале хочется — чтобы сервис, обращающийся к EntityManager и бросающий JPA exceptions, не видел был бы наружу совсем, спрятан за busness facade,
Web клиеннты, допустим на уровне зависимостей зависят лишь от последних — бизнесс интерфейсов, и ни в рантайм, ни в компайлтайм не видят javax.persistence package и его классы.
Но при этом код должен быть максимально простым для понимания. Сейчас если в каждом методе facade кетчить все JPA ексепшен, получаются, они ведут себя при попытке спрятать их между слоями — как catched exception — заставляют явно их обрабатывать программиста.
Здравствуйте, Аноним, Вы писали:
А>Добрый день,
В eclipselink можно переопределить обработчик, и обработать ексепшн как вы считаете нужным. Не сомневаюсь что и другие провайдеры дают такую возможность.
В интерсепторе будет логика по перехвату не желательных исключений и преобразованию их в более user friendly альтернативы. Т.е. вся логика будет в одном месте а не размазана по методам сервисов.
Здравствуйте, Аноним, Вы писали:
А>Добрый день,
А>Сервис, имеющий доступ к базе просает javax.persistence.EntityNotFound exception, при попытке найти запись по ID А>Это JPA exception, хотелось бы его спрятать, чтобы клиент ничего не знал о нем. А>По идее, допустум сервис — фасад для клиента (веб формы, спринг формы, servleta, не важно — facade для web слоя), должен сделать try/catch, и бросить, к примеру
А>RuntimeException("Could not find any record", jpaException)
А>Но получается, что желание оградить конечного клиента — от знания, что он имеет дела с jpa технологией или с зависимостью от jpa, приводит к усложнению обработки в facade.
А>Есть какие нибудь идеи, мысли на этот счет?
А>В идеале хочется — чтобы сервис, обращающийся к EntityManager и бросающий JPA exceptions, не видел был бы наружу совсем, спрятан за busness facade,
А>Web клиеннты, допустим на уровне зависимостей зависят лишь от последних — бизнесс интерфейсов, и ни в рантайм, ни в компайлтайм не видят javax.persistence package и его классы.
А>Но при этом код должен быть максимально простым для понимания. Сейчас если в каждом методе facade кетчить все JPA ексепшен, получаются, они ведут себя при попытке спрятать их между слоями — как catched exception — заставляют явно их обрабатывать программиста.
гуглите Exception Mapping. Стандартное решение для такого вида задачи.
