Должен ли сервисный слой вызывать исключение?

Question

Мне не нравится бросать исключения по какой-то причине, возможно, из-за хита производительности, которого я не знаю, задаваясь вопросом, следует ли мне передумать эту проблему.

Должен ли мой сервисный уровень (использует бизнес-логику Dao + и т. Д.) Бросать исключения?

public ModelAndView createProduct(@Valid ProductForm productForm, ..) { 
    ModelAndView mav = new ModelAndView(...); 

    if(bindingResult.hasErrors()) { 
    return mav; 
    } 

    // throw exception if user doesn't have permissions?? 
    productService.create(product, userPermissions); 

} 

Так что мои варианты в методе создания на ProductService:

1. , если пользователь не имеет права бросать исключение
2. возвращение какой-то объект Response, который будет иметь новый идентификатор продукта, если он был успешным, наряду с флагом успеха/сбоя и сбором ошибок.

Что нужно иметь в виду:

я могу повторно использовать этот сервис слой в не веб-приложение, а также в успокоительной веб-сервиса.

Что считается лучшей практикой?

Answer 1

Спросите себя, какие у вас есть другие варианты, иногда необходимы исключения. Единственное, что вы можете сделать, это вернуть статус сбоя или успеха и обработать его соответствующим образом.

Answer 2

Зависит от того, что вы имеете в виду по сервису и исключению, но в контексте, который у вас есть, я возьму исключение Java из конечной точки HTTP.

Ответ отрицательный. Услуги должны публиковать ошибки в общем виде. See this article on MSDN (не беспокойтесь, это вообще). В случае Restful служебных ошибок следует процитировать как статус HTTP с кодами ошибок. Служба не должна утечка деталей реализации потребителям. Это естественная граница.

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

Иду дальше, я бы сказал, что @yahir прав в том, что он говорит. HTTP-сервис будет вызывать ошибки HTTP, и, возможно, просто использовать другую службу, которая возвращает другие ошибки, но работа будет заключаться в том, чтобы обрабатывать или сопоставлять их по собственному усмотрению.

Answer 3

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

Клиенты, которые будут использовать его через RPC, будут ожидать именно этого.

Другие cilent, такие как REST, должны в любом случае получить доступ к слою услуг через какой-либо другой слой обертывания (например, слой Controller). Одна из этих обязанностей обертывания заключается в преобразовании ответа на потребительский расход.