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

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

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

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

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

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

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

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

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

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

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

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

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

Why does the NotImplementedException exist?

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

Is NotImplementedException the C# equivalent of Java's UnsupportedOperationException?

Нет, в .NET есть NotSupportedException

I have to run my algorithm, catch NotImplementedExceptions and the some how roll back my application to some sane state

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

I'm very suspicious of the NotSupportedException also... Not supported? What the? If it's not supported, why is it part of your interface?

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

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

Если IList можно или нельзя изменить, его следовало разбить на две части: одну для неизменяемой части (геттеры, поиск и т. д.), А другую - для изменяемой части (сеттеры, добавление, удаление и т. д.).

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

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

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

Есть одна ситуация, которую я считаю полезной: 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();, он работает, и это все, что имеет значение.

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

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

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

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

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

NotImplementedException

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

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

NotSupportedException

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

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

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

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

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

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

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

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

1. Вы используете NotImplementedException, чтобы указать, что член интерфейса еще не реализован, но будет. Вы комбинируете это с автоматическим модульным тестированием или тестированием QA, чтобы определить функции, которые еще необходимо реализовать.

2. Как только функция будет реализована, вы удалите NotImplementedException. Для этой функции написаны новые модульные тесты, чтобы убедиться, что она работает должным образом.

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

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

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

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

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

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

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

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

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

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

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

Таким образом, исключение предназначено для реализаций, реализующих только минимальные профили соответствия. Минимально необходимый профиль - это профиль ядра (см. ECMA-335 4-е издание - раздел IV, раздел 3), который включает BCL, поэтому исключение включено в «основной 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, все, что получено из различных потоковые классы и практически все, что имеет метод ".ToString". Что касается последней части, вы, конечно, не можете учитывать все возможные типы, поэтому сделайте их универсальными. Когда пользователь передает OurCrazyDataTypeForContainPrivateSpreadsheetData, используйте отражение, чтобы проверить наличие метода ToString, и вернуть NotSupportedException, чтобы указать на отсутствие поддержки указанных типов данных, которые не поддерживают ToString.

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

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

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

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

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

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

Две причины:

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

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

Если вы не хотите его использовать, просто проигнорируйте его. Если у вас есть блок кода, успех которого зависит от успеха каждой его части, но он может дать сбой между ними, тогда ваш единственный вариант - поймать базовый 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, он обнаружит исключение во время тестирования и осознает свою ошибку.

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

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

public void DoSomething()

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

public void DoSomething()
{
}

или же

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

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

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

Это как сказать, что код не должен компилироваться, если каждый ввод, допускающий значение NULL, не должен проверяться / обрабатываться на значение NULL. (ИНАЧЕ ошибка в триллион долларов, если не больше). Язык должен быть гибким, а тесты / контракты - твердыми.