Все защитники исключения RuntimeException/Un-checked, как бы вы справились с этим сценарием?

Question

Сценарий:

Для веб-сайта, который требует регистрации на основе идентификатора пользователя, идентификатор пользователя должен быть уникальным. Допустим, пользователь попытался зарегистрироваться с идентификатором пользователя foo, который уже существует (с другими обязательными полями). Теперь, не используя проверенные исключения (API базы данных будет бросать SQLException для дублирования вставки), мне интересно, как защитники неконтролируемого исключения обрабатывают эту ситуацию и интимные для пользователя, что идентификатор уже выбран?

Предположим, что этот веб-сайт находится на Struts (нет, я не работаю над проектом, я просто понимаю его). Пользователь отправляет заполненную информацию в Struts Action, которая вызывает DAO для вставки новой записи. Таким образом, DAO, в конечном счете, выпустит инструкцию INSERT, которая не удастся. Итак, если Action (вызов DAO) явно не обрабатывает эту ситуацию (метод DAO может просто объявить, что он выбрасывает SQLException, или метод может поймать SQLException и бросить исключение бизнес-проверки, такое как DuplicateUserIDExceptoion, которое расширяет исключение), как это можно обрабатывать с помощью неконтролируемое исключение?

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

Примечание. Я понимаю, что любой восстанавливаемый исключительный сценарий должен обрабатываться проверенным исключением (которое я реализую в своих проектах), но я действительно смущен неконтролируемым исключением ТОЛЬКО сторонников. Как вы справляетесь с этим сценарием?

Заранее благодарен.

Answer 1

Как насчет того, чтобы начать транзакцию, запросив базу данных, чтобы проверить, существует ли идентификатор, если это не так, выполнить вставку, а затем совершить транзакцию? Если он существует, сообщите пользователю, что идентификатор уже существует. Еще лучше, вы можете выполнить проверку размытия поля имени пользователя в форме как запрос ajax и указать им, что он уже выполнен. Почему вы хотите полагаться на исключение базы данных, чтобы определить, существует ли идентификатор?

Answer 2

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

1. Проверьте, существует ли идентификатор пользователя. Если да, бросьте проверенное исключение DuplicateUserIdException. Я думаю, что проверенное исключение имеет больше смысла. Но вы также можете сделать исключение временем выполнения и поймать его на уровне презентации, поскольку вы поймаете проверенное исключение.
2. введите пользователя. Если происходит SQLException, совсем не легко убедиться в том, что именно из-за уже существующего идентификатора пользователя. Кроме того, ограничение может быть проверено в момент фиксации, если оно отложено. Это исключение произойдет только в случае состояния гонки между двумя потоками и, следовательно, должно быть очень редко. Поэтому я рассматривал бы это как техническое исключение времени выполнения и отображал общее сообщение об ошибке.