Сгенерировать исключение или дать сбою

Мне интересно, есть ли плюсы и минусы против этого стиля:

private void LoadMaterial(string name)
{
    if (_Materials.ContainsKey(name))
    {
        throw new ArgumentException("The material named " + name + " has already been loaded.");
    }

    _Materials.Add(
        name,
        Resources.Load(string.Format("Materials/{0}", name)) as Material
    );
}

Этот метод должен nameбыть запущен только один раз. _Materials.Add()сгенерирует исключение, если оно будет вызываться несколько раз для одного и того же name. В результате моя охрана полностью избыточна или есть некоторые менее очевидные преимущества?

Это C #, Unity, если кому-то интересно.

Преимущество заключается в том, что ваше «пользовательское» исключение имеет сообщение об ошибке, которое имеет смысл для любого, кто вызывает эту функцию, не зная, как она реализована (что в будущем может быть вами!).

Конечно, в этом случае они, вероятно, смогут догадаться, что означает «стандартное» исключение, но вы все еще ясно даете понять, что они нарушили ваш контракт, а не наткнулись на какую-то странную ошибку в вашем коде.

Я согласен с ответом Ixrec . Тем не менее, вы можете рассмотреть третий вариант: сделать функцию идемпотентной. Другими словами, возвращайтесь раньше, чем бросайте ArgumentException. Это часто предпочтительнее, если в противном случае вы будете вынуждены проверять, была ли она уже загружена, перед LoadMaterialкаждым вызовом . Чем меньше предварительных условий, тем меньше когнитивная нагрузка на программиста.

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

Фундаментальный вопрос, который вы должны задать: каким должен быть интерфейс для вашей функции? В частности, является ли условие _Materials.ContainsKey(name)предварительным условием функции?

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

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

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

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

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

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

Для подробного объяснения проблем с классическим защитным подходом, а также возможной реализацией проверок предварительных условий в стиле assert, обратитесь к докладу Джона Лакоса « Защитное программирование, выполненное прямо из CppCon 2014» ( слайды , видео ).

Здесь уже есть несколько ответов, но вот ответ, который учитывает Unity3D (ответ очень специфичен для Unity3D, я сделал бы большую часть этого совсем по-другому в большинстве контекстов):

В общем, Unity3D не использует исключения традиционно. Если вы выбросите исключение в Unity3D, это не будет похоже на обычное приложение .NET, а именно, оно не остановит программу, в большинстве случаев вы можете настроить редактор на паузу. Это просто будет зарегистрировано. Это может легко перевести игру в недопустимое состояние и создать каскадный эффект, который затруднит отслеживание ошибок. Так что я бы сказал, что в случае с Unity разрешение Addбросить исключение является особенно нежелательным вариантом.

Но при рассмотрении скорости исключений в некоторых случаях не бывает преждевременной оптимизации из-за того, как Mono работает в Unity на некоторых платформах. На самом деле Unity3D на iOS поддерживает некоторые дополнительные оптимизации сценариев, и отключенные исключения * являются побочным эффектом одного из них. Это действительно то, что нужно учитывать, потому что эти оптимизации оказались очень ценными для многих пользователей, демонстрируя реалистичный пример рассмотрения вопроса об ограничении использования исключений в Unity3D. (* управляемые исключения из движка, а не ваш код)

Я бы сказал, что в Unity вы можете использовать более специализированный подход. По иронии судьбы, очень недооцененный ответ на момент написания этой статьи показывает, как я мог бы реализовать что-то подобное именно в контексте Unity3D (в других местах что-то подобное действительно недопустимо, и даже в Unity это довольно не элегантно).

Другой подход, который я рассмотрю, на самом деле не указывает на ошибку в том, что касается вызывающего, а скорее использует Debug.LogXXфункции. Таким образом, вы получаете то же поведение, что и создание необработанного исключения (из-за того, как Unity3D обрабатывает их), не рискуя поместить что-то в странное состояние. Также подумайте, действительно ли это ошибка (Попытка загрузить один и тот же материал дважды обязательно ошибка в вашем случае? Или это может быть Debug.LogWarningболее подходящим случаем ).

А что касается использования таких вещей, как Debug.LogXXфункции, а не исключения, вам все равно нужно учитывать, что происходит, когда исключение будет выдано из чего-то, что возвращает значение (например, GetMaterial). Я склоняюсь к этому, передавая ноль вместе с записью ошибки ( опять же, только в Unity ). Затем я использую нулевые проверки в моем MonoBehaviors, чтобы гарантировать, что любая зависимость, например материал, не является нулевым значением, и отключаю MonoBehavior, если это так. Примером простого поведения, которое требует нескольких зависимостей, является что-то вроде этого:

    public void Awake()
    {
        _inputParameters = GetComponent<VehicleInputParameters>();
        _rigidbody = GetComponent<Rigidbody>();
        _rigidbodyTransform = _rigidbody.transform;
        _raycastStrategySelector = GetComponent<RaycastStrategySelectionBehavior>();

        _trackParameters =
            SceneManager.InstanceOf.CurrentSceneData.GetValue<TrackParameters>();

        this.DisableIfNull(() => _rigidbody);
        this.DisableIfNull(() => _raycastStrategySelector);
        this.DisableIfNull(() => _inputParameters);
        this.DisableIfNull(() => _trackParameters);
    }

SceneData.GetValue<>похож на ваш пример в том, что он вызывает функцию в словаре, которая выдает исключение. Но вместо того, чтобы вызвать исключение, оно использует Debug.LogErrorтрассировку стека, как обычное исключение, и возвращает ноль. Следующие проверки * отключат поведение, а не позволят ему продолжать существовать в недопустимом состоянии.

* проверки выглядят так из-за небольшого помощника, который я использую, который печатает отформатированное сообщение, когда он отключает игровой объект **. Простые проверки нуля с ifработой здесь (** проверки помощника компилируются только в сборках отладки (например, утверждений). Использование лямбда-выражений и таких выражений в Unity может повлиять на производительность)

Мне нравятся два основных ответа, но я хочу предложить, чтобы ваши имена функций могли быть улучшены. Я привык к Java, поэтому YMMV, но метод «добавить» должен, IMO, не генерировать исключение, если элемент уже существует. Он должен снова добавить элемент или, если местом назначения является Set, ничего не делать. Поскольку это не поведение Materials.Add, его следует переименовать в TryPut, AddOnce, AddOrThrow или аналогичные.

Аналогично, ваш LoadMaterial должен быть переименован в LoadIfAbsent или Put или TryLoad или LoadOrThrow (в зависимости от того, используете ли вы ответ № 1 или № 2) или что-то подобное.

Следуйте соглашениям C # Unity по присвоению имен, какими бы они ни были.

Это будет особенно полезно, если у вас есть другие функции AddFoo и LoadBar, где допустимо загружать одно и то же дважды. Без четких имен разработчики будут разочарованы.

Все ответы добавляют ценные идеи, я хотел бы объединить их:

Определите предполагаемую и ожидаемую семантику LoadMaterial()операции. По крайней мере, существуют следующие варианты:

• Предпосылкой на name∉ LoadedMaterials : →

  Когда предварительное условие нарушается, то эффект LoadMaterial()не определен (как в ответ по ComicSansMS ). Это дает большую свободу в реализации и будущих изменениях LoadMaterial(). Или же,

• Эффекты вызова LoadMaterial(name)с name∈ LoadedMaterials указаны; или:

  • спецификация гласит, что выдается исключение; или же

  • спецификация утверждает , что результат является тождественным (как в ответе на Карле Билефельдт ),

    • возможно , возвращается «была коллекция изменила» логическое (как предложено по User949300 и предложил (в некоторых интерпретациях) по Mrlveck .

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

• Бросьте пользовательское исключение (как предложено на Ixrec ) →

  Преимущество заключается в том, что ваше «пользовательское» исключение имеет сообщение об ошибке, которое имеет значение для всех, кто вызывает эту функцию - Ixrec и User16547

  • Для того, чтобы избежать расходов , постоянно проверяя name∉ LoadedMaterials вы можете следовать Марк ван Лиувен в советуют:

    ... Вместо этого рассмотрите возможность встраивания в _Materials.Add безоговорочно, затем перехватите потенциальную ошибку и в обработчике сгенерируйте другую.

• Пусть Dictionay.Add сгенерирует исключение →

  Код выбрасывания исключений является избыточным. - Джон Рейнор

  Хотя большинство избирателей больше согласны с Ixrec

  Дополнительной причиной для выбора этой реализации являются:

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

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

• Сделать LoadMaterial()идемпотентные в anwser по Карлу Билефельдту и upvoted чаще всего ( в 75 раз).

  • возможно , возвращается «была коллекция изменила» логическое (как предложено по User949300 и предложил (в некоторых интерпретациях) по Mrlveck .

  Варианты реализации для этого поведения:

  • Проверьте с Dictionary.ContainsKey ()

  • Всегда вызывайте Dictionary.Add (), перехватывая ArgumentExceptionего, когда ключ для вставки уже существует, и игнорируйте это исключение. Документируйте, что игнорирование исключения - это то, что вы намерены делать и почему.

    • Когда LoadMaterials()это (почти) всегда вызывается один раз для каждого name, это позволяет избежать затрат , постоянно проверяя name∉ LoadedMaterials ср Марк ван Леувен . Тем не мение,
    • когда LoadedMaterials()часто вызывается несколько раз для одного и того же name, это влечет за собой (дорогие) затраты на бросание ArgumentExceptionи разматывание стека.

  • Я думал, что существует TryAddметод -метода TryGet (), который позволил бы вам избежать дорогостоящего выброса исключений и разматывания стека неудачных вызовов Dictionary.Add.

    Но этот TryAddметод, кажется, не существует.

Код выбрасывания исключений является избыточным.

Если вы позвоните:

_Materials.Add (name, Resources.Load (string.Format ("Materials / {0}", name)) как материал

с тем же ключом он бросит

System.ArgumentException

Сообщение будет: «Элемент с тем же ключом уже был добавлен».

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

В противном случае, я бы, вероятно, реорганизовал охрану в этом случае.

Я думаю, что это больше вопрос дизайна API, чем вопрос соглашения о кодировании.

Каков ожидаемый результат (контракт) звонка:

LoadMaterial("wood");

Если вызывающая сторона может ожидать / гарантируется, что после вызова этого метода загружается материал "wood", то я не вижу причин для исключения, если этот материал уже загружен.

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

Почему бы не изменить метод, чтобы он возвращал «true», если материал был добавлен, и «false», если это не так?

private bool LoadMaterial(string name)
{
   if (_Materials.ContainsKey(name))

    {

        return false; //already present
    }

    _Materials.Add(
        name,
        Resources.Load(string.Format("Materials/{0}", name)) as Material
    );

    return true;

}