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

Ответ 1

Есть одна ситуация, в которой я нахожу ее полезной: TDD.

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

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

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

EDIT: я написал правило 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();, он работает, и это все, что имеет значение.

Ответ 2

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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

Нет,.NET имеет NotSupportedException

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

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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

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

Ответ 10

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

Ответ 11

Две причины:

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

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

Ответ 12

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

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

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

Ответ 13

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

Ответ 14

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

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

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

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

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

Ответ 15

NotImplementedException

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

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

NotSupportedException

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

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

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

Ответ 16

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

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

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

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

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

Ответ 17

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

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

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

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

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

Ответ 18

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

public void DoSomething()

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

public void DoSomething()
{
}

или

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

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

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

Он, как говорящий код, не должен компилироваться, если каждый нулевой ввод не должен проверяться/обрабатываться для null. (AKA - триллионная ошибка доллара, если не больше). Язык должен быть гибким, в то время как тесты/контракты должны быть прочными.

Ответ 19

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

Ответ 20

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

Ответ 21

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

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

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

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

Ответ 22

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

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

Ответ 23

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

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

Ответ 24

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

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

Ответ 25

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

Ответ 26

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

Ответ 27

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