Для работы с базой данных, выполняющей роль справочника, используется класс-хелпер, имеющий методы addItem(Item item), getItem(String id), clearItems()... (на самом деле роль item'а может играть любая сущность, хранящаяся в справочнике, но не в этом суть).

Мой вопрос касается метода addItem(Item item): стоит ли выбрасывать наружу исключения если такой item в БД уже существует.
С одной стороны не очень удобно каждый раз заключать в try/catch блок с вызовом addItem, с другой — гасить исключение внутри метода ИМХ тоже нехорошо.

Что вы думаете по этому поводу?

Спасибо.

Здравствуйте, Serge_HID, Вы писали:

S_H>Мой вопрос касается метода addItem(Item item): стоит ли выбрасывать наружу исключения если такой item в БД уже существует.
S_H>С одной стороны не очень удобно каждый раз заключать в try/catch блок с вызовом addItem, с другой — гасить исключение внутри метода ИМХ тоже нехорошо.

S_H>Что вы думаете по этому поводу?

Пример изящного решения этой дилеммы есть в С++ в стандартной библиотеке:

std::map<int, item> somemap;
...
std::pair<std::map<int, item>::iterator, bool> inserted = somemap.insert(1, item());

Здравствуйте, Serge_HID, Вы писали:

[]

Как-то очень долго флеймил на эту тему с друзьями-джавистами. У них Add возвращает bool

Здравствуйте, Serge_HID, Вы писали:

S_H>Для работы с базой данных, выполняющей роль справочника, используется класс-хелпер, имеющий методы addItem(Item item), getItem(String id), clearItems()... (на самом деле роль item'а может играть любая сущность, хранящаяся в справочнике, но не в этом суть).

S_H>Мой вопрос касается метода addItem(Item item): стоит ли выбрасывать наружу исключения если такой item в БД уже существует.
S_H>С одной стороны не очень удобно каждый раз заключать в try/catch блок с вызовом addItem, с другой — гасить исключение внутри метода ИМХ тоже нехорошо.

S_H>Что вы думаете по этому поводу?

addItem(item) — не кидает исключение
addItemOrDie(item) — кидает
Ну типа saveItem и createItem.

Годится?

Здравствуйте, Serge_HID, Вы писали:

S_H>Мой вопрос касается метода addItem(Item item): стоит ли выбрасывать наружу исключения если такой item в БД уже существует.
S_H>С одной стороны не очень удобно каждый раз заключать в try/catch блок с вызовом addItem, с другой — гасить исключение внутри метода ИМХ тоже нехорошо.

S_H>Что вы думаете по этому поводу?

Зависит от того, что считается постусловием операции addItem. Если постусловие — вставка указанного объекта (и её последствия, например — захват ссылки на объект), то кидаем исключение или возвращаем false, то есть каким-то образом сигнализируем о том, что постусловие не выполняется. Если постусловие — такое состояние агрегата, что он содержит объект эквивалентный item, то исключения имеют смысл, если произошло нечто, не связанное с состоянием агрегата: например, оборвалась связь с сервером БД, не хватило места на диске и т.п.

Здравствуйте, Serge_HID, Вы писали:

S_H>Мой вопрос касается метода addItem(Item item): стоит ли выбрасывать наружу исключения если такой item в БД уже существует.
S_H>Что вы думаете по этому поводу?
Зависит от того, исключительная это у тебя ситуация или нормальное течение программы. Если это исключение кидает база, то глушить его никакого смысла нет — это уже исключительная ситуация. Но вообще, я лично стараюсь на дубликаты проверять перед вставкой в базу, так что до исключения базы обычно дела не доходит. Хотя, логику валидации перед сохранением один черт делаю кидающим исключения, которое упаковывает в объект исключения все ошибки, которые найдет — получается очень удобно.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Зависит от того, что считается постусловием операции addItem. Если постусловие — вставка указанного объекта (и её последствия, например — захват ссылки на объект), то кидаем исключение или возвращаем false, то есть каким-то образом сигнализируем о том, что постусловие не выполняется. Если постусловие — такое состояние агрегата, что он содержит объект эквивалентный item, то исключения имеют смысл, если произошло нечто, не связанное с состоянием агрегата: например, оборвалась связь с сервером БД, не хватило места на диске и т.п.

В принципе в данном случае постусловия как такого нет, т.е. возвращать ссылку на вставленный объект не надо — в коде дальше она использоваться не будет.
Возможно, компромиссным вариантом действительно является вариант когда гасится в методе exception по нарушению constraint, остальные же исключения — выбрасываются наружу.

Здравствуйте, Serge_HID, Вы писали:

[]

bool AddItem(...)

S_H>Мой вопрос касается метода addItem(Item item): стоит ли выбрасывать наружу исключения если такой item в БД уже существует.

ИМХО лучше всего так: в методе, где идет именно сам SQL запрос (в Data layer) надо кинуть исключение. В Business Service Layer это исключение обработать, записать как Error или Warning и по необходимости вернуть true/false.

S_H>С одной стороны не очень удобно каждый раз заключать в try/catch блок с вызовом addItem, с другой — гасить исключение внутри метода ИМХ тоже нехорошо.

На Data уровне лучше не гасить.

Здравствуйте, Serge_HID, Вы писали:

ГВ>>Зависит от того, что считается постусловием операции addItem. Если постусловие — вставка указанного объекта (и её последствия, например — захват ссылки на объект), то кидаем исключение или возвращаем false, то есть каким-то образом сигнализируем о том, что постусловие не выполняется. Если постусловие — такое состояние агрегата, что он содержит объект эквивалентный item, то исключения имеют смысл, если произошло нечто, не связанное с состоянием агрегата: например, оборвалась связь с сервером БД, не хватило места на диске и т.п.

Есть ещё одна ошибочная ситуация — когда ты пытаешься дублировать ключ не дублируя содержимое. В этом случае, по идее, нужно воспользоваться каким-нибудь updateItem, а не addItem.

S_H>В принципе в данном случае постусловия как такого нет, т.е. возвращать ссылку на вставленный объект не надо — в коде дальше она использоваться не будет.

Ну как это — нету постусловия? Есть оно, никуда не делось: агрегат содержит объект, эквивалентный item. Это и есть постусловие addItem. Осталось доопределить "эквивалентность".

S_H>Возможно, компромиссным вариантом действительно является вариант когда гасится в методе exception по нарушению constraint, остальные же исключения — выбрасываются наружу.

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