Должен ли я использовать DuplicateKeyException в своем собственном коде, отличном от LINQ? - PullRequest
3 голосов
/ 27 августа 2009

Я пишу службу аудита для некоторых важных для бизнеса операций. Услуга реализуется с использованием шаблона IoC:

public interface IAuditWriter
{
    void WriteAction(int key, string value);
}

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

Часть информации в процессе аудита включает ключ, который должен быть уникальным. В настоящее время служба требует, чтобы она обеспечивала проверку уникальности ключа в рамках процесса аудита. Дубликаты ключей являются нарушением требований процесса.

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

Обычно я ненавижу создавать новый класс исключений; почти всегда есть подходящий тип, который можно использовать для передачи одной и той же информации. Я поймал System.Data.Linq.DuplicateKeyException в прошлом, который выглядел как хороший кандидат для броска, за исключением того, что он происходит из пространства имен, связанного с LINQ, и мой интерфейс не имеет ничего общего с LINQ.

Мои ближайшие варианты:

  • бросить System.Data.Linq.DuplicateKeyException в любом случае и надеяться, что никто не прочитает слишком много в пространство имен.
  • Бросьте System.InvalidOperationException и скрестите пальцы Мне никогда не нужна реализация, которая может вызвать это исключение по другим причинам.
  • Бросай свой кастом DuplicateKeyException.
  • Создайте в интерфейсе отдельный метод для проверки уникальности ключа и вызовите его, прежде чем я напишу ключ и значение.

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

1 Ответ

5 голосов
/ 27 августа 2009

Повторное использование исключения из другого пространства имен Иногда я заимствую исключения, которые существуют в базовой платформе .NET, но я думаю, что должна быть проведена линия. Лично я попадаю в пространство имен LINQ только для повторного использования исключения, пересекающего эту линию, я бы не стал этого делать.

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

Использование пользовательского исключения DuplicateKeyException Это имеет смысл. Такое исключение является вероятным кандидатом для перехвата, поскольку вполне возможно, что код сможет что-то с этим сделать. Исключение исходит из вашего пространства имен, и вы можете добавить другие релевантные сведения, чтобы облегчить обработку исключения.

Добавить метод IsUnique Что произойдет, если между вызовом «IsUnique» и вашим методом WriteAction ключ перестанет быть уникальным, скажем, из-за изменения потока другим потоком? Этот метод может быть полезен, так как без него код может полагаться на исключения, генерируемые для его обнаружения (что было бы плохо). Однако вам все равно нужно создать исключение, если в WriteAction ключ оказывается не уникальным, нет гарантии, что потребитель интерфейса сначала даже вызовет метод IsUnique.

...