Какой тип исключения генерировать для нераспознанного параметра ID? - PullRequest
0 голосов
/ 14 апреля 2010
ITool GetTool(Guid tool)
{
    if (tool == Hammer.Id)
        return new Hammer();
    else if (tool == Drill.Id)
        return new Drill();

    else
        throw new ....?
}

Какой тип исключения наиболее подходит здесь? NotSupportedException - самое близкое, что я нашел, но я не думаю, что это совершенно правильно.

Ответы [ 6 ]

7 голосов
/ 14 апреля 2010

Я бы пошел на простой ArgumentException или ArgumentOutOfRangeException.

Описание для последнего звучит как раз для меня:

Исключение, которое выдается, когда Значение аргумента находится за пределами допустимый диапазон значений, как определено вызванным методом.

Если вы считаете набор допустимых значений «диапазоном», то это нормально, я бы сказал.

Вам определенно нужно использовать Guid здесь? Не могли бы вы иметь список допустимых инструментов вместо этого?

РЕДАКТИРОВАТЬ: Чтобы ответить на предложение создать свое собственное исключение: какую ценность это даст? Вы действительно хотите поймать это конкретное исключение? Если нет, то где выгода? Если вы поймаете это исключение, разве вы не должны проверять свои аргументы перед вызовом метода? Я считаю, что редко стоит создавать пользовательское исключение, если нет ничего подходящего.

2 голосов
/ 14 апреля 2010

По процессу устранения:

  • Создание собственного означает, что исключение является перехватываемым и может быть обработано. Это никогда не должно быть поймано, вы не можете исправить ошибки без перекомпиляции.
  • NotSupportedException означает, что ваш код виноват в том, что он не поддерживает запрошенный инструмент. Маловероятно, что у Guid триллионы недопустимых значений инструмента.
  • ArgumentOutOfRange подразумевает, что Guid слишком маленький или слишком большой. Не имеет смысла, у них нет диапазона.
  • ApplicationException теперь считается не лучшей практикой и не является достаточно конкретным.

ArgumentException ("Запрошен неизвестный инструмент")

2 голосов
/ 14 апреля 2010

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

Редактировать: я думаю, ArgumentException близок.

0 голосов
/ 14 апреля 2010

Если вам ничего не нужно, я бы сказал ArgumentException. Если вам нужен этот метод, чтобы вызвать много исключений по разным причинам и «закончились», создайте свой собственный.

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

И просто пойти немного в оффтоп (и, возможно, то, что вы уже знаете) - если вы собираетесь сгенерировать исключение, если запрос не может быть выполнен, убедитесь, что вы сначала предоставили средство проверки (например, didToolExist (инструмент Guid) )).

0 голосов
/ 14 апреля 2010

Вы должны использовать ArgumentException , поскольку проблема в том, что аргумент Guid, переданный «инструменту», не соответствует ни одному из поддерживаемых типов для этого метода. Сообщение об ошибке должно быть указано как таковое.

Однако мне кажется, что причина, по которой вас это беспокоит и трудно сказать, заключается в неловком характере дела. Этот метод, кажется, работает как фабрика, но для определенных типов, которые могут реализовать этот интерфейс. Разве Hammer не должен реализовывать свой собственный GetTool и всегда возвращать ITool типа Hammer? В противном случае вы получите то, что у вас есть, что является попыткой предвидеть того, что могут пройти все типы. Это кажется предназначенным для проблемы, если типы изменяются или добавляются новые. Затем ответственность за новый тип лежит на первоначальном методе, а не на новом типе, поддерживающем этот общий интерфейсный метод. Разве это не цель «подключаемых» классов, какие интерфейсы поощряют?

0 голосов
/ 14 апреля 2010

На первый взгляд, я бы сказал ArgumentException.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...