Викиньте виняток або нехай код не вдасться

Мені цікаво, чи є плюси і мінуси проти цього стилю:

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 #, Єдність, якщо когось цікавить.

Перевага полягає в тому, що ваш "спеціальний" виняток містить повідомлення про помилку, яке має значення для тих, хто називає цю функцію, не знаючи, як вона реалізована (якою в майбутньому ви можете бути!).

Зрозуміло, що в цьому випадку вони, ймовірно, зможуть здогадатися, що означає "стандартний" виняток, але ви все одно даєте зрозуміти, що вони порушили ваш контракт, а не натрапили на якусь дивну помилку у вашому коді.

Я згоден з відповіддю Іксрека . Однак ви можете розглянути третю альтернативу: зробити функцію idempotent. Іншими словами, повертайтеся рано, а не кидаючи ArgumentException. Це часто бажано, якщо в іншому випадку вас змусять перевірити, чи він уже завантажений, перш ніж дзвонити LoadMaterial. Чим менше у вас передумов, тим менше когнітивне навантаження на програміста.

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

Основне питання, яке ви повинні задати, це: Яким ви хочете бути інтерфейс для вашої функції? Зокрема, чи є умовою _Materials.ContainsKey(name)передумовою функції?

Якщо це не є передумовою, функція повинна забезпечувати чітко визначений результат для всіх можливих долей name. У цьому випадку виняток, викинутий якщо nameне є частиною, _Materialsстає частиною інтерфейсу функції. Це означає, що вона повинна бути частиною документації на інтерфейс, і якщо ви коли-небудь вирішите змінити цей виняток у майбутньому, це буде невід'ємною зміною інтерфейсу .

Більш цікаве питання - що відбувається, якщо це є передумовою. У цьому випадку сама передумова стає частиною інтерфейсу функції, але спосіб поведінки функції при порушенні цієї умови не обов'язково є частиною інтерфейсу.

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

Виявляється, ці недоліки можуть бути дуже істотними, що дало оборонному програмуванню вид поганої репутації в певних колах. Однак початкова мета все ще діє: Ми хочемо, щоб користувачі нашої функції помітили рано, коли вони помилилися.

Тому сьогодні багато розробників пропонують дещо інший підхід до подібних питань. Замість того, щоб кидати виняток, вони використовують механізм, схожий на затвердження, для перевірки передумов. Тобто, передумови можуть перевірятися в налагодженнях для налагодження, щоб допомогти користувачам на початку помилок, але вони не є частиною інтерфейсу функцій. Різниця може здатися тонкою на перший погляд, але вона може змінити величезну практику.

Технічно викликати функцію з порушеними передумовами - це невизначена поведінка. Але реалізація може вирішити виявити ці випадки та повідомити користувача одразу, якщо це станеться. На жаль, винятки не є хорошим інструментом для цього, оскільки код користувача може реагувати на них і, таким чином, може почати покладатися на їх присутність.

Детальне пояснення проблем із класичним оборонним підходом, а також можлива реалізація перевірок передумов у стилі ствердження див. У розмові « Оборонне програмування» Джона Лакоса, виконане справа від CppCon 2014 ( Слайди , відео ).

Тут вже є кілька відповідей, але ось відповідь, яка враховує Unity3D (відповідь дуже специфічна для Unity3D, я б зробив більшість цього зовсім по-різному в більшості контекстів):

Загалом, Unity3D традиційно не використовує винятків. Якщо ви викинете виняток у Unity3D, він не схожий на ваш середній додаток .NET, а саме він не зупинить програму, t більшість ви можете налаштувати редактор на паузу. Він просто зареєструється. Це може легко поставити гру в недійсний стан і створити ефект каскаду, що ускладнює відстеження помилок. Тому я б сказав, що у випадку Unity, дозволити Addвикинути виняток є особливо небажаним варіантом.

Але при вивченні швидкості виключень в деяких випадках не відбувається передчасної оптимізації через те, як Mono працює в Unity на деяких платформах. Насправді Unity3D на iOS підтримує деякі розширені оптимізації сценаріїв, а виключені виключення * є побічним ефектом одного з них. Це дійсно щось, що слід враховувати, оскільки ці оптимізації виявились дуже цінними для багатьох користувачів, показуючи реалістичний випадок розгляду обмеження на використання винятків у Unity3D. (* керовані винятки з двигуна, а не ваш код)

Я б сказав, що в Unity ви можете скористатися більш спеціалізованим підходом. За іронією долі, на момент написання цього запиту, дуже невдоволена відповідь , показує один із способів, як я можу реалізувати щось подібне конкретно в контексті Unity3D (в інших місцях щось подібне насправді неприйнятно, і навіть в Unity це досить неелегантно).

Ще один підхід, який я вважаю, насправді не вказує на помилку, що стосується абонента, а скоріше використання Debug.LogXXфункцій. Таким чином, ви отримуєте таку саму поведінку, як кидати необроблений виняток (через те, як Unity3D поводиться з ними), не ризикуючи поставити щось у дивному стані вниз. Також врахуйте, чи справді це помилка (намагається завантажити один і той же матеріал двічі, обов'язково помилка у вашому випадку? Або це може бути випадок, коли Debug.LogWarningце більше стосується).

Що стосується використання таких речей, як Debug.LogXXфункції, а не винятки, вам все одно доведеться враховувати, що відбувається, коли виняток буде викинуто з чогось, що повертає значення (наприклад, GetMaterial). Я схильний підходити до цього, передаючи null разом із реєстрацією помилки ( знову ж таки, лише в 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що дає слід стека, як звичайний виняток, і повертає null. Наступні перевірки * відключать поведінку замість того, щоб продовжувати існувати у недійсному стані.

* чеки виглядають так через маленького помічника, який використовує, який виводить форматоване повідомлення, коли він відключає ігровий об’єкт **. Прості нульові перевірки з ifроботою тут (** перевірки помічників збираються лише у налагодженнях налагодження (наприклад, твердження). Використання лямбдів і виразів, подібних до Unity, може спричинити справність)

Мені подобаються дві основні відповіді, але хочу припустити, що назви ваших функцій можна було б покращити. Я звик до Java, тому YMMV, але метод "add" повинен, IMO, не кидати виняток, якщо елемент вже є. Він повинен знову додати елемент , або, якщо пунктом призначення є Набір, нічого не робити. Оскільки це не поведінка Materials.Add, її слід перейменувати в TryPut або AddOnce або AddOrThrow або подібне.

Так само ваш LoadMaterial повинен бути перейменований на LoadIfAbsent або Put або TryLoad або LoadOrThrow (залежно від того, використовуєте ви відповідь №1 або №2) або деякі подібні.

Дотримуйтесь конвенцій про іменування C # Unity, якими б вони не були.

Це буде особливо корисно, якщо у вас є інші функції AddFoo та LoadBar, де дозволено завантажувати одну і ту ж річ двічі. Без чітких імен розробники зірвуться.

Усі відповіді додають цінні ідеї, я хотів би їх поєднати:

Визначтеся із наміченою та очікуваною семантикою LoadMaterial()операції. Принаймні існують такі варіанти:

• Обов’язкова умова для name∉ завантаженихматеріалів : →

  Коли попередня умова порушується, то ефект LoadMaterial()не визначений (як в відповідь по ComicSansMS ). Це дозволяє отримати найбільшу свободу у здійсненні та майбутніх змінах Росії LoadMaterial(). Або,

• визначено ефекти виклику за LoadMaterial(name)допомогою name∈ LoadedMaterials ; або:

  • специфікація зазначає, що викид викинуто; або

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

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

Вирішивши семантику, ви повинні вибрати реалізацію. Наступні варіанти та міркування, де пропонується:

• Киньте призначене для користувача виняток (як запропоновано на Ixrec ) →

  Перевага полягає в тому, що ваш "спеціальний" виняток містить повідомлення про помилку, яке має значення для всіх, хто викликає цю функцію - Ixrec та User16547

  • Щоб уникнути витрат на повторну перевірку name∉ Завантаженихматеріалів, ви можете дотримуватися поради Марка ван Левену :

    ... Замість цього подумайте про те, щоб зануритися у _Materials.Add беззастережно, тоді вловити потенційну помилку і в обробник кинути іншу.

• Нехай Dictionay.Add кине виняток →

  Код, що кидає виняток, є зайвим. - Джон Рейнор

  Хоча більшість виборців більше погоджуються з Ixrec

  Додатковою причиною вибору цієї реалізації є:

  • що абоненти вже можуть обробляти ArgumentExceptionвинятки, і
  • щоб уникнути втрати інформації про стеки.

  Але якщо ці дві причини є важливими, ви також можете отримати власний виняток ArgumentExceptionі використовувати оригінал як прикутий виняток.

• Зробити LoadMaterial()ідемпотентна в anwser по Карлу Білефельдта і upvoted найчастіше ( в 75 разів).

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

  Варіанти реалізації такої поведінки:

  • Зверніться до слова.ContainsKey ()

  • Завжди зателефонуйте до словника.Add () ловіть його, який ArgumentExceptionвін кидає, коли ключ для вставки вже існує, і ігноруйте цей виняток. Документуйте, що ігнорування винятку - це те, що ви маєте намір робити і чому.

    • Коли LoadMaterials()(майже) завжди викликається один раз для кожного name, це дозволяє уникнути витрат, які неодноразово перевіряються name∉ LoadedMaterials пор. Марк ван Левен . Однак,
    • коли LoadedMaterials()його часто називають декількома разів за одне і те ж name, це вимагає (дорогої) вартості закидання ArgumentExceptionта розмотування стека.

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

    Але цей TryAdd-метод, схоже, не існує.

Код, що кидає виняток, є зайвим.

Якщо ви телефонуєте:

_Materials.Add (ім'я, Resources.Load (string.Format ("Матеріали / {0}", ім'я)) як Матеріал

тим самим ключем він кине a

System.ArgumentException

Повідомлення буде: "Елемент з тим самим ключем уже додано."

ContainsKeyПеревірка є зайвою , оскільки по суті таку ж поведінку досягається без нього. Єдиний елемент, який відрізняється - це фактичне повідомлення за винятком. Якщо справжня вигода від отримання спеціального повідомлення про помилку є, то захисний код має певні заслуги.

В іншому випадку я б, мабуть, відмовився від охорони в цій справі.

Я думаю, це скоріше питання щодо дизайну API, ніж питання конвенції кодування.

Який очікуваний результат (контракт) дзвінка:

LoadMaterial("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;

}