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

NotImplementedException

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

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

NotSupportedException

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

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

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

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

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

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

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

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

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

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

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

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

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

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

нет.NET имеет NotSupportedException

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я думаю, что вы запутаете шифрование с скомпилированным двоичным двоином .

Даже коммерческое программное обеспечение для замкнутого исходного кода, такое как Microsoft Office или Adobe Photoshop для распределения . Но они скомпилированы на родной машинный код, который делает их трудно обратным инженером.

JavaScript не имеет такой вещи, как скомпилированная бинара. Но, поскольку все больше и больше браузеров перемещаются к сборке BYTECODE для достижения более быстрой производительности, мы можем когда-нибудь иметь скомпилированный формат источника JavaScript. Возможно, аналогично Python's .py и .pyc . Pyep файлы , может быть, у нас будет .jsc или javaScript Compited файл, который может быть доставлен в браузер В двоичной форме, чтобы запустить на своем виртуальной машине JavaScript.

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

Две причины:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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