Попытка добавить дубликат в набор - какое исключение бросить?

Question

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

Вот тест (ы):

public function testFluentInterface() 
{ 
    $sport = new Sport(); 
    $this->assertSame($sport, $sport->addCode('ANY'), 
    'Expected Sport to implement fluent interface.' 
); 
} 

public function testCannotAddSameCodeMoreThanOnce() 
{ 
    $code = 'BAZ'; 

    $sport = new Sport(); 
    $sport->addCode($code); 

    try 
    { 
    $sport->addCode($code); 
    $this->fail(
     'Expected error when trying to add the same code to a sport more than once.' 
    ); 
    } 
    catch(/*SomeKindOf*/Exception $e) 
    { 
    } 
} 

Сначала я думал, что это может быть соответствующим для OverflowException быть выброшен в этом случае, но я не уверен, является ли «уже существует это значение» такая же, как «этот контейнер заполнен»:

Исключение, когда вы добавляете элемент в полный контейнер.

Там в UnexpectedValueException, но это, кажется, больше относится к переменным с неправильными типами:

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

Я всегда мог использовать LogicException, но это кажется немного родовым для этого случая использования:

Exception, который представляет ошибку в логике программы. Подобные исключения должны непосредственно привести к исправлению в вашем коде.

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

Answer 1

Чем больше я думаю об этом - особенно в свете соответствующих ответов Тони и Фрэнсиса - тем больше я задаюсь вопросом, полезно ли в этом случае бросать исключение.

Точка точки Тони, многие классы уже обрабатывают эту ситуацию по-разному. Хотя возврат значения «отказ» в данном случае не является опцией (класс Sport реализует свободный интерфейс), попытка дважды добавить объект в коллекцию не обязательно является «исключительным» случаем.

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

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

Другими словами, если цель заключается в следующем:

$sport 
    ->addCode($codeA) 
    ->addCode($codeB) 
    ->setSomeOtherProperties(...) 
    ->save(); 

Тогда это не имеет никакого смысла, чтобы заставить разработчиков, чтобы сделать это:

if(! $sport->hasCode($codeA)) 
{ 
    $sport->addCode($codeA); 
} 
// etc. - Why bother having a fluent interface if it's unsafe to use it? 

Приведенный выше код является особенно проблематичным, поскольку addCode() все равно вызовет hasCode(), что фактически заставляет разработчика вызывать дублирование вычислений.

И с помощью TRY/поймать не намного лучше:

try 
{ 
    $sport 
    ->addCode($codeA) 
    ->addCode($codeB) 
    ->setSomeOtherProperties(...) 
    ->save(); 
} 
catch(LogicException $e) 
{ 
    // $sport is now in an unknown state. 
} 

Пытаясь оправиться от LogicException в вышеуказанном блок непрактично, и это не должно быть даже здесь необходимо; попытка добавить код дважды не должна быть достаточной для остановки объекта Sport.

Answer 2

В качестве примера многие классы в Java Collection Framework (т. Е. Set) не генерируют исключения в таких случаях, они возвращают false.

Лично я бы пошел таким образом.

Answer 3

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

/** 
* Raised when item is added to a collection multiple times. 
*/ 
class DuplicateException extends RuntimeException {}; 

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