¿Por qué existe NotImplementedException?

https://stackoverflow.com/questions/410719

03-07-2019
|

Pregunta

Esto realmente me inquieta, así que espero que alguien pueda darme una justificación razonable de por qué las cosas son como son.

NotImplementedException. Estás tirando de mi pierna, ¿verdad?

No, no voy a tomar la puñalada barata diciendo: "Espera, el método está implementado, arroja una excepción NotImplementedException". Sí, es cierto, debe implementar el método para lanzar una NotImplementedException (a diferencia de una llamada de función virtual pura en C ++, ¡ahora eso tiene sentido!). Si bien eso es bastante gracioso, hay un problema más grave en mi mente.

Me pregunto, en presencia de NotImplementedException, ¿cómo puede alguien hacer algo con .Net? ¿Se espera que finalice cada llamada de método abstracto con un bloque try catch para protegerse de métodos que podrían no implementarse? Si detectas una excepción, ¿qué diablos se supone que debes hacer con ella?

No veo forma de probar si un método se implementa realmente sin llamarlo. Dado que llamarlo puede tener efectos secundarios, no puedo hacer todos mis controles por adelantado y luego ejecutar mi algoritmo. Tengo que ejecutar mi algoritmo, capturar NotImplementedExceptions y de alguna manera hacer retroceder mi aplicación a un estado sensato.

Es una locura. Enojado. Insano. Entonces la pregunta es: ¿Por qué existe la excepción NotImplementedException ?

Como huelga preventiva, no quiero que nadie responda, "porque los diseñadores deben poner esto en el código generado automáticamente". Esto es horrible Prefiero que el código generado automáticamente no se compile hasta que proporcione una implementación. Por ejemplo, la implementación generada automáticamente podría ser '' lanzar NotImplementedException; '' donde la NotImplementedException no está definida!

¿Alguien ha atrapado y manejado alguna vez una excepción NotImplementedException? ¿Alguna vez ha dejado una excepción NotImplementedException en su código? Si es así, ¿esto representó una bomba de tiempo (es decir, lo dejó accidentalmente allí) o una falla de diseño (el método no debe implementarse y nunca se llamará)?

También sospecho mucho de NotSupportedException ... ¿No es compatible? ¿Que? Si no es compatible, ¿por qué forma parte de su interfaz? ¿Alguien en Microsoft puede deletrear herencia incorrecta? Pero podría comenzar otra pregunta para eso si no obtengo demasiado abuso para esta.

Información adicional:

Esta es una lectura interesante sobre el tema.

Parece haber un fuerte acuerdo con Brad Abrams that " NotImplementedException es para la funcionalidad que aún no se ha implementado, pero que realmente debería (y lo será). Algo parecido a lo que podría comenzar cuando está creando una clase, obtenga todos los métodos lanzando NotImplementedException, luego enjuáguelos con código real & # 8230; "

Comentarios de Jared Parsons son muy débiles y probablemente deberían ignorarse: NotImplementedException: Lanza esta excepción cuando un tipo no implementa un método por cualquier otro motivo.

El MSDN es aún más débil en el tema, simplemente indicando eso, "La excepción que se produce cuando no se implementa un método u operación solicitada."

Solución

Hay una situación que me parece útil: TDD.

Escribo mis pruebas, luego creo stubs para que las pruebas se compilen. Esos trozos no hacen nada más que lanzar una nueva NotImplementedException (); . De esta manera, las pruebas fallarán de manera predeterminada, sin importar qué. Si usé algún valor de retorno ficticio, podría generar falsos positivos. Ahora que todas las pruebas se compilan y fallan porque no hay implementación, abordo esos trozos.

Como nunca uso una NotImplementedException en ninguna otra situación, ninguna NotImplementedException pasará al código de lanzamiento, ya que siempre hará que algunas pruebas fallen.

No necesitas atraparlo por todas partes. Las buenas API documentan las excepciones lanzadas. Esos son los que debes buscar.

EDITAR: escribí una regla de FxCop para encontrarlos.

Este es el código:

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);
        }
    }
}

Y este es el metadato de la regla:

<?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>

Para construir esto necesitas:

referencia Microsoft.FxCop.Sdk.dll y Microsoft.Cci.dll
Coloque los metadatos en un archivo llamado DesignRules.xml y agréguelo como un recurso incrustado a su ensamblaje
Asigne un nombre a su ensamblaje Bevonn.CodeAnalysis . Si desea utilizar nombres diferentes para los metadatos o los archivos de ensamblaje, asegúrese de cambiar el segundo parámetro al constructor base en consecuencia.

Luego simplemente agregue el ensamblaje resultante a sus reglas de FxCop y elimine esas malditas excepciones de su precioso código. Hay algunos casos de esquina en los que no informará una excepción NotImplementedException cuando se lanza una, pero realmente creo que no tiene remedio si en realidad está escribiendo ese código cthulhian. Para usos normales, es decir, lanzar nueva NotImplementedException (); , funciona, y eso es todo lo que importa.

Otros consejos

Está ahí para admitir un caso de uso bastante común, una API funcional pero solo parcialmente completada. Digamos que quiero que los desarrolladores prueben y evalúen mi API: WashDishes () funciona, al menos en mi máquina, pero todavía no he podido codificar DryDishes () , y mucho menos PutAwayDishes () . En lugar de fallar silenciosamente o dar un mensaje de error críptico, puedo ser bastante claro acerca de por qué DryDishes () no funciona, todavía no lo he implementado.

Su excepción hermana NotSupportedException tiene sentido principalmente para los modelos de proveedor. Muchos lavavajillas tienen una función de secado, por lo que pertenece a la interfaz, pero mi lavavajillas con descuento no lo admite. Puedo dejar que eso se conozca a través de NotSupportedException

Resumiré mis puntos de vista sobre esto en un solo lugar, ya que están dispersos en algunos comentarios:

Utiliza NotImplementedException para indicar que un miembro de la interfaz aún no está implementado, pero lo estará. Combina esto con pruebas unitarias automatizadas o pruebas de control de calidad para identificar características que aún deben implementarse.
Una vez que se implementa la función, elimina la NotImplementedException . Se escriben nuevas pruebas unitarias para la función para garantizar que funcione correctamente.
NotSupportedException se usa generalmente para proveedores que no admiten funciones que no tienen sentido para tipos específicos. En esos casos, los tipos específicos arrojan la excepción, los clientes los atrapan y los manejan según corresponda.
La razón por la que tanto NotImplementedException como NotSupportedException existen en el Framework es simple: las situaciones que conducen a ellas son comunes, por lo que tiene sentido definirlas en el Framework, para que los desarrolladores no tengan que seguir redefiniéndolos. Además, facilita a los clientes saber qué excepción atrapar (especialmente en el contexto de una prueba unitaria). Si tiene que definir su propia excepción, tienen que averiguar qué excepción atrapar, que es al menos un sumidero de tiempo contraproducente y con frecuencia incorrecta.

¿Por qué NotImplementedException? existe?

NotImplementedException es una excelente manera de decir que algo aún no está listo. Por qué no está listo es una pregunta separada para los autores del método. En el código de producción, es poco probable que atrape esta excepción, pero si lo hizo, puede ver de inmediato lo que sucedió y es mucho mejor que tratar de averiguar por qué se llamaron los métodos, pero no sucedió nada o, lo que es peor, reciba algunos "temporales". resultado y obtener "divertido" efectos secundarios.

IsImplementedException the C # equivalente de Java UnsupportedOperationException?

No, .NET tiene NotSupportedException

Tengo que ejecutar mi algoritmo, atrapar NotImplementedExceptions y algunos cómo revertir mi aplicación a alguna estado cuerdo

Good API tiene documentación de métodos XML que describe posibles excepciones.

Sospecho mucho de la NotSupportedException también ... No ¿soportado? ¿Que? Si no es compatible, ¿por qué es parte de su interfaz?

Puede haber millones de razones. Por ejemplo, puede introducir una nueva versión de API y no desea / no puede admitir métodos antiguos. Nuevamente, es mucho mejor ver una excepción descriptiva en lugar de profundizar en la documentación o depurar código de terceros.

El uso principal para una excepción NotImplementedException es en el código auxiliar generado: ¡de esa manera no se olvide de implementarlo! Por ejemplo, Visual Studio implementará explícitamente los métodos / propiedades de una interfaz con el cuerpo lanzando una NotImplementedException.

Re NotImplementedException : esto sirve para algunos usos; Proporciona una única excepción que (por ejemplo) las pruebas de su unidad pueden bloquear por trabajo incompleto. Pero también, realmente hace lo que dice: esto simplemente no está allí (todavía). Por ejemplo, "mono" lanza esto por todas partes para los métodos que existen en las bibliotecas de MS, pero que aún no se han escrito.

Re NotSupportedException : no todo está disponible. Por ejemplo, muchas interfaces admiten un par "¿puedes hacer esto?" / " hacer esto " ;. Si el "¿puedes hacer esto?" devuelve falso, es perfectamente razonable para el "hacer esto" para lanzar NotSupportedException . Los ejemplos pueden ser IBindingList.SupportsSearching / IBindingList.Find () etc.

La mayoría de los desarrolladores de Microsoft están familiarizados con los patrones de diseño en los que es apropiada una excepción NotImplementedException. Es bastante común en realidad.

Un buen ejemplo es un Patrón compuesto , donde muchos objetos se pueden tratar como un solo instancia de un objeto. Un componente se utiliza como una clase abstracta base para clases de hoja heredadas (correctamente). Por ejemplo, una clase de Archivo y Directorio puede heredar de la misma clase base abstracta, porque son tipos muy similares. De esta forma, se pueden tratar como un solo objeto (lo que tiene sentido cuando se piensa en qué archivos y directorios son; en Unix, por ejemplo, todo es un archivo).

Entonces, en este ejemplo, habría un método GetFiles () para la clase Directory, sin embargo, la clase File no implementaría este método, porque no tiene sentido hacerlo. En su lugar, obtienes una NotImplementedException, porque un archivo no tiene hijos como un directorio.

Tenga en cuenta que esto no se limita a .NET: encontrará este patrón en muchos lenguajes y plataformas OO.

¿Por qué siente la necesidad de detectar todas las excepciones posibles? ¿También ajusta cada llamada al método con catch (NullReferenceException ex) ?

El código auxiliar que arroja NotImplementedException es un marcador de posición, si hace que se libere debería ser un error como NullReferenceException .

Creo que hay muchas razones por las cuales MS agregó NotImplementedException al marco:

Como conveniencia; Dado que muchos desarrolladores lo necesitarán durante el desarrollo, ¿por qué todos deberían tener el suyo?
Para que las herramientas puedan confiar en su presencia; por ejemplo, "Implementar interfaz" de Visual Studio El comando genera stubs de método que generan NotImplementedException. Si no estuviera en el marco, esto no sería posible, o al menos bastante incómodo (por ejemplo, podría generar código que no se compila hasta que agregue su propia NotImplementedException)
Fomentar una práctica estándar coherente "

Frankodwyer piensa que NotImplementedException es una bomba de tiempo potencial. Diría que cualquier código inacabado es una bomba de tiempo, pero NotImplementedException es mucho más fácil de desarmar que las alternativas. Por ejemplo, puede hacer que su servidor de compilación analice el código fuente para todos los usos de esta clase y los informe como advertencias. Si realmente quiere prohibirlo, incluso podría agregar un enlace de precompromiso a su sistema de control de fuente que evite el registro de dicho código.

Claro, si lanza su propia NotImplementedException, puede eliminarla de la compilación final para asegurarse de que no queden bombas de tiempo. Pero esto solo funcionará si usa su propia implementación de manera consistente en todo el equipo, y debe asegurarse de no olvidar eliminarla antes de su lanzamiento. Además, es posible que no pueda eliminarlo; tal vez hay algunos usos aceptables, por ejemplo, para probar el código que no se envía a los clientes.

Realmente no hay ninguna razón para realmente capturar una excepción NotImplementedException. Cuando se golpea, debería matar tu aplicación y hacerlo muy dolorosamente. La única forma de solucionarlo no es atrapándolo, sino cambiando su código fuente (ya sea implementando el método llamado o cambiando el código de llamada).

Dos razones:

Los métodos se desactivan durante el desarrollo y lanzan la excepción para recordar a los desarrolladores que su escritura de código no ha finalizado.
Implementación de una interfaz de subclase que, por diseño, no implementa uno o más métodos de la clase o interfaz base heredada. (Algunas interfaces son demasiado generales).

Esto me parece un campo minado potencial. En el pasado distante, una vez trabajé en un sistema de red heredado que había estado funcionando sin parar durante años y que cayó un día. Cuando rastreamos el problema, encontramos un código que claramente no se había terminado y que nunca podría haber funcionado, literalmente, como si el programador fuera interrumpido durante la codificación. Era obvio que esta ruta de código en particular nunca se había tomado antes.

La ley de Murphy dice que algo similar solo está pidiendo que suceda en el caso de NotImplementedException. Concedido en estos días de TDD, etc., debe recogerse antes del lanzamiento, y al menos puede codificar esa excepción antes del lanzamiento, pero aún así.

Cuando se realiza la prueba, es difícil garantizar la cobertura de cada caso, y esto parece que dificulta su trabajo al hacer que los problemas de tiempo de ejecución de lo que podrían haber sido problemas de tiempo de compilación. (Creo que un tipo similar de 'deuda técnica' viene con sistemas que dependen en gran medida del 'tipeo de patos', aunque reconozco que son muy útiles).

Necesita esta excepción para la interoperabilidad COM. Es E_NOTIMPL . El blog vinculado también muestra otras razones

Lanzar NotImplementedException es la forma más lógica para que el IDE genere compilación de código auxiliar. Como cuando extiendes la interfaz y haces que Visual Studio la apague por ti.

Si hiciste un poco de C ++ / COM, eso también existía allí, excepto que se conocía como E_NOTIMPL .

Hay un caso de uso válido para ello. Si está trabajando en un método particular de una interfaz que desea que compile el código para poder depurarlo y probarlo. Según su lógica, necesitaría eliminar el método de la interfaz y comentar el código auxiliar que no se compila. Este es un enfoque muy fundamentalista y, aunque tiene mérito, no todos se adherirán a eso. Además, la mayoría de las veces desea que la interfaz esté completa.

Tener una excepción NotImplementedException identifica muy bien qué métodos aún no están listos, al final del día es tan fácil como presionar Ctrl + Shift + F para encontrarlos todos, también estoy seguro de que el código estático las herramientas de análisis también lo recogerán.

No debe enviar código que tenga la excepción NotImplementedException . Si cree que al no usarlo puede mejorar su código, continúe, pero hay cosas más productivas que puede hacer para mejorar la calidad de la fuente.

NotImplementedException

La excepción se produce cuando no se implementa un método u operación solicitada.

Hacer de esto una única excepción definida en el núcleo de .NET hace que sea más fácil encontrarlos y erradicarlos. Si cada desarrollador creara su propio ACME.EmaNymton.NotImplementedException , sería más difícil encontrarlos todos.

NotSupportedException

La excepción se produce cuando no se admite un método invocado.

Por ejemplo, cuando hay un intento de leer, buscar o escribir en una secuencia que no admite la funcionalidad invocada.

Por ejemplo, los iteradores generados (usando la palabra clave yield ) es-a IEnumerator , pero el método IEnumerator.Reset arroja NotSupportedException .

De ECMA-335, la especificación CLI, específicamente los tipos de biblioteca CLI, System.NotImplementedException, sección de comentarios:

" Varios implementaciones y tipos, especificados en otra parte de este Estándar, no son necesarios para las implementaciones de CLI que se ajustan solo al Perfil de Kernel. Por ejemplo, el conjunto de características de punto flotante consta de los tipos de datos de punto flotante System.Single y System.Double. Si el soporte para estos se omite de una implementación, cualquier intento de hacer referencia a una firma que incluya los tipos de datos de punto flotante da como resultado una excepción del tipo System.NotImplementedException. & Quot;

Entonces, la excepción está destinada a implementaciones que implementan solo perfiles de conformidad mínimos. El perfil mínimo requerido es el Kernel Profile (ver ECMA-335 4ta edición - Partición IV, sección 3), que incluye el BCL, por lo que la excepción se incluye en el '' núcleo API '', y no en otra ubicación.

El uso de la excepción para denotar métodos apagados, o para métodos generados por el diseñador que carecen de implementación es entender mal la intención de la excepción.

En cuanto a por qué esta información NO se incluye en la documentación de MSDN para la implementación de la CLI por parte de MS está más allá de mí.

No puedo responder por NotImplementedException (estoy de acuerdo con su punto de vista), pero he usado NotSupportedException ampliamente en la biblioteca principal que utilizamos en el trabajo. DatabaseController, por ejemplo, le permite crear una base de datos de cualquier tipo compatible y luego usar la clase DatabaseController en el resto del código sin preocuparse demasiado por el tipo de base de datos que se encuentra debajo. Bastante básico, ¿verdad? Donde NotSupportedException es útil (y donde hubiera utilizado mi propia implementación si ya no existiera) son dos instancias principales:

1) Migrar una aplicación a una base de datos diferente A menudo se argumenta que esto rara vez, si alguna vez, sucede o es necesario. Bullsh * t. Obtenga más información.

2) Misma base de datos, controlador diferente El ejemplo más reciente de esto fue cuando un cliente que usa una aplicación respaldada por Access actualizó de WinXP a Win7 x64. Al no ser un controlador JET de 64 bits, su técnico de TI instaló el AccessDatabaseEngine en su lugar. Cuando nuestra aplicación se bloqueó, pudimos ver fácilmente desde el registro que era DB.Connect se bloqueó con NotSupportedException, que pudimos abordar rápidamente. Otro ejemplo reciente fue uno de nuestros programadores que intentaba usar transacciones en una base de datos de Access. Aunque Access admite transacciones, nuestra biblioteca no admite transacciones de Access (por razones que están fuera del alcance de este artículo). NotSupportedException, ¡es tu momento de brillar!

3) Funciones genéricas No puedo pensar en un conciso "por experiencia" ejemplo aquí, pero si piensa en algo como una función que agrega un archivo adjunto a un correo electrónico, desea que pueda tomar algunos archivos comunes como JPEG, cualquier cosa derivada de varias clases de flujo y prácticamente cualquier cosa que tenga un " ;. ToString " método. Para la última parte, ciertamente no puede dar cuenta de todos los tipos posibles, por lo que lo hace genérico. Cuando un usuario pasa OurCrazyDataTypeForContainingProprietarySpreadsheetData, use la reflexión para comprobar la presencia de un método ToString y devuelva NotSupportedException para indicar la falta de soporte para dichos tipos de datos que no admiten ToString.

NotSupportedException de ninguna manera es una característica crucial, pero es algo que me encuentro usando mucho más mientras trabajo en proyectos más grandes.

Digamos que tiene este método en su código de producción

public void DoSomething()

¿Cuál tomarías si quieres dejarlo más tarde para terminar?

public void DoSomething()
{
}

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

Ciertamente tomaría el segundo. Junto con Elmah o cualquier mecanismo de registro de errores que tenga (implementado como un aspecto en toda su aplicación). Junto con el filtro de registro / excepción para activar la notificación de correo electrónico de error crítico cuando se detecta uno.

El argumento de que NotImplementedException == sin terminar tampoco es correcto. (1) La captura de métodos no implementados debe dejarse a pruebas unitarias / pruebas de integración. Si tiene una cobertura del 100% (lo que debería hacer ahora, con tantas herramientas de generación de simulacros / código auxiliar) sin NotImplementedException, ¿cuáles son sus preocupaciones? (2) Generación de código. Llano simple Nuevamente, si genero el código, y solo uso la mitad del código generado, ¿por qué no habría NotImplementedException en el resto del código auxiliar generado?

Es como decir que el código no debe compilarse a menos que cada entrada anulable deba verificarse / manejarse como nula. (También conocido como el error del billón de dólares, si no más). El lenguaje debe ser flexible, mientras que las pruebas / contratos deben ser sólidos.

Raramente lo uso para arreglar la interfaz. Suponga que tiene una interfaz que debe cumplir pero que nadie llamará a cierto método, por lo que debe pegar una excepción NotImplementedException y, si alguien la llama, sabrá que está haciendo algo mal.

NotImplementedException se lanza para algún método de .NET (consulte el analizador C # en Code DOM que no está implementado, ¡pero el método existe!) Puede verificar con este método Microsoft.CSharp.CSharpCodeProvider.Parse

Ambos son hacks para dos problemas comunes.

NotImplementedException es una solución para los desarrolladores que son astronautas de la arquitectura y les gusta escribir primero la API, luego el código. Obviamente, dado que este no es un proceso incremental, no puede implementarlo todo a la vez y, por lo tanto, quiere fingir que está casi terminado lanzando NotImplementedException.

NotSupportedException es un truco en torno a la limitación de los sistemas de tipos como los que se encuentran en C # y Java. En estos sistemas de tipos, usted dice que un Rectángulo 'es una' Forma si el Rectángulo hereda todas las características de las Formas (incluidas las funciones miembro + variables). Sin embargo, en la práctica, esto no es cierto. Por ejemplo, un cuadrado es un rectángulo, pero un cuadrado es una restricción de un rectángulo, no una generalización.

Entonces, cuando desea heredar y restringir el comportamiento de la clase padre, lanza NotSupported en métodos que no tienen sentido para la restricción.

¿Qué pasa con los prototipos o proyectos inacabados?

No creo que sea una mala idea usar una excepción (aunque en ese caso utilizo un cuadro de mensaje).

Bueno, estoy un poco de acuerdo. Si una interfaz se ha creado de tal manera que no todas las clases pueden implementar todos los bits de ella, en mi opinión, debería haberse desglosado.

Si IList puede o no modificarse, debería haberse dividido en dos, uno para la parte no modificable (captadores, búsqueda, etc.) y otro para la parte modificable (establecedores, agregar, eliminar, etc. ).

Tengo algunas NotImplementedExceptions en mi código. Muchas veces proviene de parte de una interfaz o clase abstracta. Creo que algunos métodos que necesito en el futuro tienen sentido como parte de la clase, pero no quiero tomarme el tiempo para agregarlos a menos que realmente los necesite. Por ejemplo, tengo una interfaz para todos los tipos individuales de estadísticas en mi juego. Uno de esos tipos es un ModStat, que es la suma de la estadística base más todos los modificadores (es decir, armas, armaduras, hechizos). Mi interfaz de estadísticas tiene un evento OnChanged, pero mi ModStat funciona calculando la suma de todas las estadísticas a las que hace referencia cada vez que se llama. Entonces, en lugar de generar la carga de una tonelada de eventos ModStat.OnChange cada vez que cambia una estadística, solo tengo una NotImplementedException lanzada si alguien intenta agregar / eliminar un escucha a OnChange.

Los lenguajes .NET tienen que ver con la productividad, entonces, ¿por qué gastar su tiempo codificando algo que ni siquiera usará?

Aquí hay un ejemplo: en Java, cada vez que implemente la interfaz Iterator , debe anular los métodos obvios hasNext () y next () , pero también hay delete () . En el 99% de los casos de uso que tengo, no necesito esto, así que solo lanzo una NotImplementedException . Esto es mucho mejor que no hacer nada en silencio.

La excepción NotImplementedException solo existe para facilitar el desarrollo. Imagine que comienza a implementar una interfaz. Le gustaría poder construir al menos cuando haya terminado de implementar un método, antes de pasar al siguiente. Stubbing de los métodos NotImplemented con NotImplementedExceptions es una excelente manera de vivir el código inacabado que es muy fácil de detectar más adelante. De lo contrario, correría el riesgo de implementar rápidamente algo que podría olvidar arreglar.

Si no quieres usarlo, simplemente ignóralo. Si tiene un bloque de código cuyo éxito depende de que cada parte tenga éxito, pero puede fallar en el medio, entonces su única opción es capturar la base Exception y revertir lo que necesita ser revertido . Olvídese de NotImplementedException . Podría haber toneladas de excepciones, como MyRandomException y GtfoException y OmgLolException . Después de escribir originalmente el código, podría pasar y lanzar OTRO tipo de excepción desde la API a la que está llamando. Uno que no existía cuando escribiste tu código. Maneje los que sabe cómo manejar y revierta para cualquier otro, es decir, catch (Exception) . Es bastante simple, creo ... Me parece útil también. Especialmente cuando intentas cosas sofisticadas con el lenguaje / marco que ocasionalmente te imponen cosas.

Un ejemplo que tengo es la serialización. He agregado propiedades en mi biblioteca .NET que no existen en la base de datos (por ejemplo, envoltorios convenientes sobre propiedades '' tontas '' existentes, como una propiedad FullName que combina FirstName , MiddleName y LastName ). Luego quiero serializar estos tipos de datos a XML para enviarlos por cable (por ejemplo, desde una aplicación ASP.NET a JavaScript), pero el marco de serialización solo serializa propiedades públicas con get y < code> set accesores. No quiero que pueda configurar FullName porque entonces tendría que analizarlo y podría haber algún formato imprevisto que analice incorrectamente y la integridad de los datos se salga por la ventana. Es más fácil usar las propiedades subyacentes para eso, pero dado que el lenguaje y la API requieren que tenga un acceso set , arrojaré una NotImplementedException (no estaba consciente de NotSupportedException hasta que lea este hilo, pero cualquiera de los dos funciona) de modo que si algún programador en el futuro intenta establecer FullName , encontrará la excepción durante las pruebas y darse cuenta de su error.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow