Найдите, был ли SQLException брошен из-за дубликата
Глядя на вашу фотографию, я думаю, что речь идет о клавиатуре Razer.
У меня такой же, и когда я смотрю в программное обеспечение Synapse, чтобы увидеть, что на самом деле делают макрокнопки, я вижу, что они по умолчанию отключены Можно настроить их на нажатие определенной клавиши, комбинации клавиш или чего-то в этом роде.
Поэтому мой подход заключается в том, чтобы настроить макрос для какой-то комбинации клавиш и прослушать это в вашем приложении. (Очевидно, это будет работать только на вашем компьютере и потребует дополнительной настройки для любого другого пользователя, использующего ваш инструмент)
8 ответов
С основным JDBC действительно нет способа сделать то, что Вы говорите способом перекрестной базы данных. Поскольку Вы упомянули, что getErrorCode мог использоваться, но потребовал определенных для поставщика кодов ошибок.
Этими только тремя путями я вижу для двигений, это:
- Используйте своего рода платформу, которая делает весь перевод от кода ошибки до значимых исключений (Будьте в спящем режиме, вероятно, сделал бы это, кто-то еще упомянул, что Spring делает),
- Проверьте на дубликат вручную (с выбором) до выполнения Вашей вставки. (Это не было бы 100%, как его технически возможный, что кто-то, возможно, сделал вставку после Вашего запроса).
- После того, как Вы получите любое sql исключение на вставке, попытайтесь запросить для того идентификатора. Если можно на самом деле найти соответствие - можно быть абсолютно уверены, что ошибка, которую Вы получили, происходила из-за дублирующегося первичного ключа. (Хотя его возможное, что были многочисленные проблемы, и это не было на самом деле тем, которое было брошено).
Моя рекомендация состояла бы в том, чтобы написать Ваш код для предотвращения проблемы как можно больше, и затем (если абсолютно необходимый), используйте № 3.
Это точно, для чего SQLException.getSQLState (). Acoording к Google, "23000" указывает на нарушение ограничения на уникальность данных, по крайней мере, в MySQL, PostgreSQL и Oracle.
Я полагаю, что простой и надежный путь состоит в том, чтобы проверить, существует ли ключ до выполнения вставки. Как Вы справедливо указали, каждая база данных имеет свой собственный способ сообщить об ошибке.
Я пропускаю что-то? При использовании JDBC, необходимо возвратить дублирующееся ключевое исключение, независимо от используемого DB.
Или Вы спрашивали, как Вы определите dupkey перед попыткой вставки?
Ну, если Вы не можете полагаться на исключение, чтобы сказать Вам, почему оно было брошено, Вы могли протестировать следующим исключение с "избранным количеством (*) от таблицы где ключ = @keyfailedtoinsert";
К сожалению, исключение, как гарантируют, не даст Вам имя таблицы и ключевое имя. В некоторых случаях код Java, который назвал названным драйвером JDBC, никогда не мог иметь их, например, если вставка произошла wihin хранимая процедура, или как в триггере.
Таким образом, Вы вернулись к необходимости доверять поставщику каждого драйвера JDBC.
Вы могли "обучить" программу на запуске (или конфигурация) путем вставки известного делают дубликат ключа и запись брошенного кода ошибки.
Я предполагаю, что Вы не используете JDBC, или это было бы очень простым ошибочным поиском.
У Вас есть другой набор классов для доступа к различным базам данных? Если так, Вы могли поймать исключение в базе данных определенные классы и бросить Ваш собственный тип исключительной ситуации, который является общим для все типы БД.
Я думаю, что идеальное решение состояло бы в том, чтобы иметь слой данных, выдают определенное исключение в этом случае, возможно, подкласс SQLException для DuplicateKeyException или что-то подобное.
Если Вы хотите смочь рассматривать различные исключения по-другому, то необходимо бросить различные типы исключительной ситуации (или подтипы) для начала.
Я думаю, что это - область, где Платформа Spring получает вещи, действительно правильные: они обеспечивают очень богатую иерархию "исключений базы данных", все из которых расширяют DataAccessException, с поддеревьями типов для "восстанавливаемых исключений", "переходные исключения", "исключения целостности данных", и т.д. и т.д. Это оставляет Ваш клиентский код бесплатным поймать любого (или ни один) типов исключительной ситуации, которые он может обработать или заботиться о: исключения, которые указывают на ошибку, которая не может быть повторяемой, если Вы повторно выполняете транзакцию, фатальную неисправимую ошибку, или можно просто поймать корневой тип.