Почему не существует исключения NotImplementedException?

https://stackoverflow.com/questions/410719

03-07-2019
|

Вопрос

Это очень, очень раздражает меня, поэтому я надеюсь, что кто-нибудь сможет дать мне разумное обоснование, почему все так, как есть.

Исключение NotImplementedException. Ты меня разыгрываешь, верно?

Нет, я не собираюсь прибегать к дешевой уловке, говоря: "Подождите, метод реализован - он выдает исключение NotImplementedException". Да, это верно, вы должны реализовать метод для вызова NotImplementedException (в отличие от чисто виртуального вызова функции в C ++ - теперь это имеет смысл!).Хотя это чертовски забавно, на мой взгляд, есть более серьезная проблема.

Мне просто интересно, при наличии исключения NotImplementedException, как кто-либо может что-либо сделать с .Net?Ожидается ли, что вы будете оборачивать каждый вызов абстрактного метода блоком try catch для защиты от методов, которые могут быть не реализованы?Если вы поймаете такое исключение, какого черта вы должны с ним делать??

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

Это безумие.Сумасшедший.Безумный.Итак, вопрос заключается в следующем: Почему существует исключение NotImplementedException?

В качестве упреждающего удара я не хочу, чтобы кто-нибудь ответил: "потому что дизайнерам нужно включить это в автоматически сгенерированный код". Это ужасно.Я бы предпочел, чтобы автоматически сгенерированный код не компилировался до тех пор, пока вы не предоставите реализацию.Например, автоматически сгенерированной реализацией может быть "throw NotImplementedException;", где NotImplementedException не определено!

Кто-нибудь когда-нибудь перехватывал и обрабатывал NotImplementedException?Вы когда-нибудь оставляли NotImplementedException в своем коде?Если да, представляло ли это бомбу замедленного действия (т. Е. вы случайно оставили ее там) или недостаток дизайна (метод не должен быть реализован и никогда не будет вызван)?

Я также очень подозрительно отношусь к исключению NotSupportedException...Не поддерживается?Что за?Если он не поддерживается, почему он является частью вашего интерфейса?Может ли кто-нибудь в Microsoft написать по буквам "неправильное наследование"?Но я мог бы задать другой вопрос по этому поводу, если меня не будут слишком сильно ругать за этот.

Дополнительная информация:

Это это интересное чтение на эту тему.

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

Комментарии от Джаред Парсонс они очень слабы и, вероятно, их следует игнорировать:Исключение NotImplementedException:Генерирует это исключение, когда тип не реализует метод по какой-либо другой причине.

Тот Самый MSDN является еще более слабым по этому вопросу, просто заявляя, что "Исключение, которое выдается, когда запрошенный метод или операция не реализованы".

Решение

Есть одна ситуация, я нахожу это полезным:TDD.

Я пишу свои тесты, затем создаю заглушки, чтобы тесты компилировались.Эти заглушки не делают ничего, кроме throw new NotImplementedException();.Таким образом, тесты по умолчанию завершатся неудачей, несмотря ни на что.Если бы я использовал какое-то фиктивное возвращаемое значение, это могло бы привести к ложным срабатываниям.Теперь, когда все тесты компилируются и завершаются неудачей из-за отсутствия реализации, я занимаюсь этими заглушками.

Поскольку я никогда не использую NotImplementedException в любой другой ситуации - нет NotImplementedException когда-нибудь перейдет в код выпуска, поскольку это всегда приведет к сбою какого-либо теста.

Вам не нужно ловить его повсюду.Хорошие API документируют создаваемые исключения.Это те, на кого вам следует обратить внимание.

Редактировать:Я написал правило FxCop, чтобы найти их.

Это и есть код:

using System;
using Microsoft.FxCop.Sdk;

/// <summary>
/// An FxCop rule to ensure no <see cref="NotImplementedException"/> is
/// left behind on production code.
/// </summary>
internal class DoNotRaiseNotImplementedException : BaseIntrospectionRule
{
    private TypeNode _notImplementedException;
    private Member _currentMember;

    public DoNotRaiseNotImplementedException()
        : base("DoNotRaiseNotImplementedException",
               // The following string must be the assembly name (here
               // Bevonn.CodeAnalysis) followed by a dot and then the
               // metadata file name without the xml extension (here
               // DesignRules). See the note at the end for more details.
               "Bevonn.CodeAnalysis.DesignRules",
               typeof (DoNotRaiseNotImplementedException).Assembly) { }

    public override void BeforeAnalysis()
    {
        base.BeforeAnalysis();
        _notImplementedException = FrameworkAssemblies.Mscorlib.GetType(
            Identifier.For("System"),
            Identifier.For("NotImplementedException"));
    }

    public override ProblemCollection Check(Member member)
    {
        var method = member as Method;
        if (method != null)
        {
            _currentMember = member;
            VisitStatements(method.Body.Statements);
        }
        return Problems;
    }

    public override void VisitThrow(ThrowNode throwInstruction)
    {
        if (throwInstruction.Expression != null &&
            throwInstruction.Expression.Type.IsAssignableTo(_notImplementedException))
        {
            var problem = new Problem(
                GetResolution(),
                throwInstruction.SourceContext,
                _currentMember.Name.Name);
            Problems.Add(problem);
        }
    }
}

И это метаданные правила:

<?xml version="1.0" encoding="utf-8" ?>
<Rules FriendlyName="Bevonn Design Rules">
  <Rule TypeName="DoNotRaiseNotImplementedException" Category="Bevonn.Design" CheckId="BCA0001">
    <Name>Do not raise NotImplementedException</Name>
    <Description>NotImplementedException should not be used in production code.</Description>
    <Url>http://stackoverflow.com/questions/410719/notimplementedexception-are-they-kidding-me</Url>
    <Resolution>Implement the method or property accessor.</Resolution>
    <MessageLevel Certainty="100">CriticalError</MessageLevel>
    <Email></Email>
    <FixCategories>NonBreaking</FixCategories>
    <Owner></Owner>
  </Rule>
</Rules>

Чтобы построить это, вам нужно:

ссылка Microsoft.FxCop.Sdk.dll и Microsoft.Cci.dll
Поместите метаданные в файл под названием DesignRules.xml и добавьте его в качестве встроенного ресурса в вашу сборку
Назовите свою сборку Bevonn.CodeAnalysis.Если вы хотите использовать разные имена либо для метаданных, либо для файлов сборки, убедитесь, что вы соответствующим образом изменили второй параметр на базовый конструктор.

Затем просто добавьте полученную сборку в свои правила FxCop и уберите эти проклятые исключения из вашего драгоценного кода.Есть несколько угловых случаев, когда он не будет сообщать об исключении NotImplementedException при его возникновении, но я действительно думаю, что вы безнадежны, если вы на самом деле пишете такой ктулхианский код.Для обычного использования, т.е. throw new NotImplementedException();, это работает, и это все, что имеет значение.

Другие советы

Он предназначен для поддержки довольно распространенного варианта использования, работающего, но лишь частично завершенного API.Допустим, я хочу, чтобы разработчики протестировали и оценили мой API - WashDishes() работает, по крайней мере, на моей машине, но я еще не дошел до кодирования DryDishes(), не говоря уже о PutAwayDishes().Вместо того чтобы молча терпеть неудачу или выдавать какое-то загадочное сообщение об ошибке, я могу совершенно ясно объяснить, почему DryDishes() не работает - я еще не реализовал это.

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

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

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

Почему существует NotImplementedException ?

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

Является ли NotImplementedException C# эквивалентом Java UnsupportedOperationException?

Нет, .NET не поддерживает исключение

Я должен запустить свой алгоритм, перехватить NotImplementedExceptions и некоторые другие как откатить мое приложение до некоторого вменяемого состояния

В Good API есть документация по методам XML, которая описывает возможные исключения.

Я также с большим подозрением отношусь к исключению NotSupportedException...Не поддерживается?Что за?Если это не поддерживается, почему это часть вашего интерфейса?

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

Основное применение исключения NotImplementedException заключается в сгенерированном коде-заглушке:таким образом, вы не забудете это реализовать!!Например, Visual Studio явно реализует методы / свойства интерфейса с телом, вызывающим исключение NotImplementedException .

Ре NotImplementedException - это служит нескольким целям;он предоставляет единственное исключение, которое (например) ваши модульные тесты могут заблокировать из-за незавершенной работы.Но кроме того, он действительно делает то, что говорит:этого просто нет (пока).Например, "mono" использует это повсеместно для методов, которые существуют в библиотеках MS, но еще не были написаны.

Ре NotSupportedException - не все доступно.Например, многие интерфейсы поддерживают пару "ты можешь это сделать?" / "сделай это".Если "вы можете это сделать?" возвращает false , вполне разумно, чтобы "сделать это" выдавало NotSupportedException.Примерами могут быть IBindingList.SupportsSearching / IBindingList.Find() и т.д.

Большинство разработчиков в Microsoft знакомы с шаблонами проектирования, в которых уместно исключение NotImplementedException.На самом деле это довольно распространенное явление.

Хорошим примером является Составной Узор, где множество объектов можно рассматривать как один экземпляр объекта.Компонент используется в качестве базового абстрактного класса для (должным образом) унаследованных конечных классов.Например, класс File и Directory могут наследоваться от одного и того же абстрактного базового класса, поскольку они очень похожи по типам.Таким образом, их можно рассматривать как единый объект (что имеет смысл, когда вы думаете о том, что такое файлы и каталоги - например, в Unix все является файлом).

Итак, в этом примере для класса Directory должен быть метод GetFiles(), однако класс File не будет реализовывать этот метод, потому что это не имеет смысла делать.Вместо этого вы получаете NotImplementedException , потому что у файла нет дочерних элементов, как у Каталога.

Обратите внимание, что это не ограничивается .NET - вы столкнетесь с этим шаблоном во многих OO-языках и платформах.

Почему вы чувствуете необходимость перехватывать все возможные исключения?Вы завершаете каждый вызов метода с помощью catch (NullReferenceException ex) тоже?

Выбрасывание заглушки кода NotImplementedException является заполнителем, если он позволяет его выпустить, это должна быть ошибка точно так же, как NullReferenceException.

Я думаю, есть много причин, по которым MS добавила NotImplementedException в фреймворк:

Для удобства;поскольку многим разработчикам это понадобится во время разработки, почему каждый должен создавать что-то свое?
Чтобы инструменты могли полагаться на его наличие;например, команда Visual Studio "Реализовать интерфейс" генерирует заглушки методов, которые вызывают исключение NotImplementedException.Если бы этого не было в фреймворке, это было бы невозможно или, по крайней мере, довольно неудобно (например, это могло бы сгенерировать код, который не компилируется до тех пор, пока вы не добавите свое собственное исключение NotImplementedException)
Поощрять последовательную "стандартную практику"

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

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

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

Две причины:

Методы отключаются во время разработки и выдают исключение, чтобы напомнить разработчикам, что написание их кода еще не завершено.
Реализация интерфейса подкласса, который по своей конструкции не реализует один или несколько методов унаследованного базового класса или интерфейса.(Некоторые интерфейсы просто слишком общие.)

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

Закон Мерфи гласит, что нечто подобное просто напрашивается на то, чтобы произойти в случае NotImplementedException .Конечно, в наши дни TDD и т.д., Это должно быть подобрано перед выпуском, и, по крайней мере, вы можете использовать grep-код для этого исключения перед выпуском, но все же.

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

Вам нужно это исключение для COM-взаимодействия. Это E_NOTIMPL.Связанный блог также показывает другие причины

Бросание NotImplementedException это наиболее логичный способ для IDE сгенерировать код-заглушку для компиляции.Например, когда вы расширяете интерфейс и заставляете Visual Studio заглушить его для вас.

Если вы немного поработали с C ++ / COM, это тоже существовало там, за исключением того, что оно было известно как E_NOTIMPL.

Для этого есть допустимый вариант использования.Если вы работаете над определенным методом интерфейса, вы хотите, чтобы ваш код был скомпилирован, чтобы вы могли отлаживать и тестировать его.Согласно вашей логике, вам нужно было бы удалить метод из интерфейса и закомментировать некомпилируемый код-заглушку.Это очень фундаменталистский подход, и, хотя в нем есть свои достоинства, не все будут или должны его придерживаться.Кроме того, в большинстве случаев вы хотите, чтобы интерфейс был полным.

Наличие NotImplementedException прекрасно определяет, какие методы еще не готовы, в конце концов, это так же просто, как нажать Ctrl+Shift+F чтобы найти их все, я также уверен, что инструменты статического анализа кода тоже это поймут.

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

Исключение NotImplementedException

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

Включение этого единственного исключения, определенного в .NET core, упрощает их поиск и устранение.Если бы каждый разработчик должен был создавать свои собственные ACME.EmaNymton.NotImplementedException было бы труднее найти их все.

Исключение NotSupportedException

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

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

Например, сгенерированные итераторы (с использованием yield ключевое слово) -это-a IEnumerator, но тот IEnumerator.Reset метод бросает NotSupportedException.

Из ECMA-335, спецификации CLI, в частности, типов библиотек CLI, System.Исключение NotImplementedException, раздел замечаний:

"Ряд типов и конструкций, указанных в другом месте этого Стандарта, не требуются для реализаций CLI, которые соответствуют только профилю ядра.Например, набор функций с плавающей запятой состоит из типов данных с плавающей запятой System.Single и System.Double.Если поддержка для них отсутствует в реализации, любая попытка сослаться на сигнатуру, которая включает типы данных с плавающей запятой, приводит к исключению типа System.NotImplementedException."

Таким образом, исключение предназначено для реализаций, которые реализуют только минимальные профили соответствия.Минимально необходимый профиль - это профиль ядра (см. ECMA-335 4th edition - Раздел IV, раздел 3), который включает BCL, именно поэтому исключение включено в "core API", а не в какое-либо другое место.

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

Относительно того, почему эта информация НЕ включена в документацию MSDN по реализации командной строки MS, я не понимаю.

Я не могу ручаться за NotImplementedException (я в основном согласен с вашим мнением), но я широко использовал NotSupportedException в базовой библиотеке, которую мы используем на работе.DatabaseController, например, позволяет вам создать базу данных любого поддерживаемого типа, а затем использовать класс DatabaseController в остальной части вашего кода, не слишком заботясь о типе базы данных под ней.Довольно простые вещи, не так ли?Где пригодится NotSupportedException (и где я бы использовал свою собственную реализацию, если бы она еще не существовала), так это два основных экземпляра:

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

2) Та же база данных, другой драйвер Последний пример этого был, когда клиент, использующий приложение с поддержкой Access, обновился с WinXP до Win7 x64.Поскольку у них не было 64-разрядного драйвера JET, их ИТ-специалист установил вместо него AccessDatabaseEngine.Когда наше приложение вышло из строя, мы могли легко увидеть из журнала, что это был сбой DB.Connect с NotSupportedException, который мы быстро смогли устранить.Другим недавним примером была попытка одного из наших программистов использовать транзакции в базе данных Access.Несмотря на то, что Access поддерживает транзакции, наша библиотека не поддерживает транзакции Access (по причинам, выходящим за рамки этой статьи).NotSupportedException, пришло ваше время блистать!

3) Общие функции Я не могу придумать здесь краткий пример "из опыта", но если вы подумаете о чем-то вроде функции, которая добавляет вложение к электронному письму, вы хотите, чтобы она могла принимать несколько обычных файлов, таких как JPEG, все, что получено из различных классов stream, и практически все, что имеет ".Метод "toString".Что касается последней части, вы, конечно, не можете учитывать все возможные типы, поэтому вы делаете его универсальным.Когда пользователь передает OurCrazyDataTypeForContainingProprietarySpreadsheetData, используйте отражение для проверки наличия метода toString и возвращайте NotSupportedException, чтобы указать на отсутствие поддержки для указанных типов данных, которые не поддерживают toString .

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

Допустим, у вас есть этот метод в вашем производственном коде

public void DoSomething()

Какой из них вы бы выбрали, если бы хотели оставить его на доработку позже?

public void DoSomething()
{
}

или

public void DoSomething()
{
    throw new NotImplementedException();
}

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

Аргумент, что NotImplementedException == незавершенный, также неверен.(1) Отлов нереализованных методов следует оставить на усмотрение модульных тестов / интеграционных тестов.Если у вас есть 100% покрытие (что вы должны сейчас сделать, используя так много инструментов для создания макетов / заглушек / кода) без NotImplementedException, что вас беспокоит?(2) Генерация кода.Все очень просто.Опять же, если я сгенерирую код и использую только половину сгенерированного кода, почему у меня не будет NotImplementedException в остальной части сгенерированной заглушки?

Это все равно что сказать, что код не должен компилироваться до тех пор, пока каждый вводимый с нулевым значением не будет проверен / обработан на null.(ОНА ЖЕ ошибка на триллион долларов, если не больше).Язык должен быть гибким, в то время как тесты / контракты должны быть надежными.

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

NotImplementedException выдается для некоторого метода .NET (см. синтаксический анализатор C # в Code DOM, который не реализован, но метод существует!) Вы можете проверить с помощью этого метода Microsoft.CSharp.CSharpCodeProvider.Анализировать

Оба они являются взломами для решения двух распространенных проблем.

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

NotSupportedException - это попытка обойти ограничение систем типов, подобных тем, что встречаются в C # и Java.В этих системах типов вы говорите, что Прямоугольник "является" Фигурой, если Прямоугольник наследует все характеристики Фигур (включаяфункции-члены + переменные).Однако на практике это не так.Например, Квадрат - это Прямоугольник, но Квадрат - это ограничение Прямоугольника, а не обобщение.

Поэтому, когда вы хотите наследовать и ограничить поведение родительского класса, вы создаете NotSupported для методов, которые не имеют смысла для ограничения.

А как насчет прототипов или незаконченных проектов?

Я не думаю, что это действительно плохая идея - использовать исключение (хотя в этом случае я использую messagebox).

Что ж, я в чем-то согласен.Если интерфейс был создан таким образом, что не все классы могут реализовать все его фрагменты, то, на мой взгляд, он должен был быть разбит.

Если IList может или не может быть изменен, его следовало бы разбить на два, один для неизменяемой части (getters, lookup и т.д.) И один для изменяемой части (setters, add, remove и т.д.).

У меня есть несколько NotImplementedExceptions в моем коде.Часто это происходит из части интерфейса или абстрактного класса.Некоторые методы, которые, как я чувствую, мне могут понадобиться в будущем, имеют смысл как часть класса, но я просто не хочу тратить время на добавление, если мне это действительно не нужно.Например, у меня есть интерфейс для всех отдельных видов статистики в моей игре.Одним из таких видов является ModStat, который представляет собой сумму базовых характеристик плюс все модификаторы (то есть оружие, броня, заклинания).В моем интерфейсе статистики есть событие OnChanged, но мой ModStat работает путем вычисления суммы всех статистических данных, на которые он ссылается при каждом вызове.Таким образом, вместо того, чтобы иметь накладные расходы в виде тонны ModStat.События onChange возникают каждый раз, когда изменяется статистика, у меня просто возникает исключение NotImplementedException, если кто-либо пытается добавить / удалить прослушиватель в onChange.

Все языки .NET нацелены на производительность, так зачем тратить свое время на кодирование того, что вы даже не будете использовать?

Вот один из примеров:В Java всякий раз, когда вы реализуете интерфейс Iterator, вы должны переопределить очевидные методы hasNext() и next(), но есть также delete().В 99% случаев использования, которые у меня есть, мне это не нужно, поэтому я просто бросаю NotImplementedException.Это гораздо лучше, чем молча ничего не делать.

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

Если вы не хотите им пользоваться, просто игнорируйте его.Если у вас есть блок кода, успех которого зависит от успеха каждой его части, но между ними может произойти сбой, тогда ваш единственный вариант - перехватить базу Exception и откатите то, что нужно откатить.Забыть NotImplementedException.Может быть выброшено множество исключений, таких как MyRandomException и GtfoException и OmgLolException.После того, как вы изначально напишете код, я мог бы зайти и выдать ДРУГОЙ тип исключения из API, который вы вызываете.Тот, которого не существовало, когда вы писали свой код.Обработайте те, с которыми вы знаете, как обращаться, и выполните откат для любых других, т.е., catch(Exception).По-моему, это довольно просто...Я нахожу, что это тоже бывает кстати.Особенно, когда вы пробуете необычные вещи с языком / фреймворком, которые иногда навязывают вам что-то новое.

Один из примеров, который у меня есть, - это сериализация.Я добавил в свою библиотеку .NET свойства, которых нет в базе данных (например, удобные оболочки поверх существующих "немых" свойств, таких как FullName свойство, сочетающее в себе FirstName, MiddleName, и LastName).Затем я хочу сериализовать эти типы данных в XML, чтобы отправлять их по проводам (например, из приложения ASP.NET в JavaScript), но платформа сериализации сериализует только общедоступные свойства с обоими get и set аксессуары.Я не хочу, чтобы ты мог устанавливать FullName потому что тогда мне пришлось бы его разобрать, и мог возникнуть какой-то непредвиденный формат, который я неправильно проанализирую, и целостность данных исчезнет из окна.Для этого проще просто использовать базовые свойства, но поскольку язык и API требуют, чтобы у меня был set аксессуар, я подброшу NotImplementedException (Я не был в курсе NotSupportedException пока я не прочитал эту тему, но любая из них работает), так что, если какой-нибудь программист в будущем попытается установить FullName он столкнется с исключением во время тестирования и осознает свою ошибку.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow