Por que NotImplementedException existe?

https://stackoverflow.com/questions/410719

03-07-2019
|

Pergunta

Este realmente, realmente me urks, então eu espero que alguém pode me dar uma justificação razoável para por que as coisas são como são.

NotImplementedException. Você está puxando a minha perna, certo?

Não, eu não vou tomar a facada barato a isso dizendo, "hang on, o método é implementado -. Ele lança um NotImplementedException" Sim, isso mesmo, você tem que implementar o método para lançar um NotImplementedException (ao contrário de uma chamada de função virtual pura em C ++ - agora que faz sentido). Enquanto isso é muito muito engraçado, não é um problema mais sério em minha mente.

Eu só quero saber, na presença do NotImplementedException, como alguém pode fazer qualquer coisa com .net? Você está prevista para envolver cada chamada método abstrato com um bloco try catch para se proteger contra métodos que não podem ser implementadas? Se você pegar uma exceção tal, o que diabos você está suposto fazer com ele ??

Eu não vejo nenhuma maneira de testar se um método é realmente implementado sem chamá-lo. Desde chamando ele pode ter efeitos colaterais, eu não posso fazer todos os meus cheques up-front e, em seguida, executar o meu algoritmo. Eu tenho que correr o meu algoritmo, NotImplementedExceptions captura eo de alguma forma reverter a minha candidatura a algum estado sã.

É uma loucura. Louco. Insano. Então a questão é:? Por que a exist NotImplementedException

Como um ataque preventivo, eu não quero que ninguém a responder com "porque os designers precisam colocar isso no código gerado automaticamente." Isso é horrível. Eu prefiro o código gerado automaticamente não compilar até que você fornecer uma implementação. Por exemplo, a implementação auto gerado poderia ser "jogar NotImplementedException;" onde o NotImplementedException não está definida!

Alguém já capturados e manipulados a NotImplementedException? Alguma vez você já deixou uma NotImplementedException em seu código? Se sim, isso representa uma bomba de tempo (ou seja, você acidentalmente deixou lá), ou uma falha de projeto (o método não deve ser implementado e nunca será chamada)?

Eu sou muito suspeito do NotSupportedException também ... Não suportado? O que? Se não é suportado, por que é parte de sua interface? qualquer pessoa, a Microsoft pode significar herança imprópria? Mas eu poderia começar outra pergunta para que, se eu não ficar muito abusar para este.

Informações adicionais:

este é uma leitura interessante sobre o assunto.

Parece haver uma forte concordância com Brad Abrams que "NotImplementedException é para a funcionalidade que ainda não é apenas implementada, mas realmente deve (e será). Algo parecido com o que você pode start com quando você está construindo uma classe, obter todos os métodos lá jogando NotImplementedException, em seguida, lave-os para fora com código real ... "

Jared Parsons são muito fracos e provavelmente deve ser ignorado: NotImplementedException: lançar essa exceção quando um tipo não implementa um método para qualquer outra razão

O MSDN é ainda mais fraco sobre o assunto, apenas afirmando que, "A exceção que é acionada quando um método ou operação solicitada não está implementada."

Solução

Há uma situação que eu achar que é útil:. TDD

Eu escrevo meus testes, então eu criar recibos de modo que os testes de compilar. Esses recibos de fazer nada, mas throw new NotImplementedException();. Desta forma, os testes irão falhar por padrão, não importa o quê. Se eu usei algum valor de retorno manequim, pode gerar falsos positivos. Agora que todos os testes compilar e falham porque não há nenhuma implementação, eu lidar com esses tocos.

Desde que eu nunca use um NotImplementedException em qualquer outra situação, não NotImplementedException nunca vai passar para código de liberação, uma vez que sempre vai fazer algum teste falhar.

Você não precisa pegá-lo em todo o lugar. Boas APIs documentar as exceções lançadas. Aqueles são os que você deve procurar.

EDIT:. Eu escrevi uma regra FxCop para encontrá-los

Este é o 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);
        }
    }
}

E este é o metadados regra:

<?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 isso, você precisa:

referência Microsoft.FxCop.Sdk.dll e Microsoft.Cci.dll
Coloque os metadados em um arquivo chamado DesignRules.xml e adicioná-lo como um recurso incorporado à sua montagem
Nome do seu Bevonn.CodeAnalysis montagem. Se você quiser usar nomes diferentes para ambos os metadados ou os arquivos de montagem, certifique-se de alterar o segundo parâmetro para o construtor base em conformidade.

Em seguida, basta adicionar o resultando montagem para suas regras FxCop e tomar essas exceções malditos fora de seu código precioso. Existem alguns casos de canto onde ele não irá relatar um NotImplementedException quando um é jogado, mas eu realmente acho que você é inútil se você está realmente escrever tal código cthulhian. Para usos normais, ou seja throw new NotImplementedException();, ele funciona, e isso é tudo que importa.

Outras dicas

É lá para apoiar um caso de uso bastante comum, um trabalho, mas API apenas parcialmente concluída. Digamos que eu queira desenvolvedores para testar e avaliar meus API - obras WashDishes(), pelo menos na minha máquina, mas em torno de ainda não ter chegado a codificação até DryDishes(), muito menos PutAwayDishes(). Ao invés de silenciosamente falhar, ou dar alguma mensagem de erro enigmática, eu posso ser muito claro sobre o porquê DryDishes() não funciona -. Eu não implementaram ainda

A sua exceção irmã NotSupportedException faz sentido principalmente para modelos de provedor. Muitas máquinas de lavar louça têm uma função de secagem, de modo pertence à interface, mas a minha máquina de lavar louça desconto não apoiá-lo. Eu posso deixar isso ser conhecido através do NotSupportedException

Vou resumir a minha opinião sobre isso em um só lugar, uma vez que eles estão espalhados por toda alguns comentários:

Você usa NotImplementedException para indicar que um membro de interface ainda não está implementado, mas será. Você pode combinar isso com unidade de testes automatizados ou QA testes para identificar características que ainda precisam ser implementadas.
Uma vez que o recurso é implementado, você remove o NotImplementedException. Novos testes de unidade são escritos para o recurso para garantir que ele funciona corretamente.
NotSupportedException é geralmente usado para provedores que não suportam características que não fazem sentido para tipos específicos. Nesses casos, os tipos específicos lançar a exceção, os clientes pegá-los e tratá-los conforme o caso.
A razão que ambos existem NotImplementedException e NotSupportedException no Quadro é simples: as situações que levam a eles são comuns, por isso faz sentido para defini-los no quadro, de modo que os desenvolvedores não tem que manter a redefinição eles. Além disso, torna mais fácil para os clientes para saber qual exceção catch (especialmente no contexto de um teste de unidade). Se você tem que definir a sua própria exceção, eles têm que descobrir qual exceção a captura, que é, no mínimo, uma pia tempo contraproducente, e freqüentemente incorretos.

Por que o NotImplementedException existe?

NotImplementedException é uma ótima maneira de dizer que algo não está pronto ainda. Por que ele não está pronto é uma questão separada para autores do método. No código de produção é improvável que você pegar essa exceção, mas se você fez você pode ver imediatamente o que aconteceu e é muito melhor do que tentar descobrir por métodos foi chamado, mas não aconteceu nada ou, pior ainda - receber algum resultado "temporário" e get "engraçados" efeitos colaterais.

é NotImplementedException o C # equivalente de Java de UnsupportedOperationException?

Não, NET tem NotSupportedException

Eu tenho que correr o meu algoritmo, captura NotImplementedExceptions ea alguns como reverter a minha candidatura a algum Estado sã

Boa API tem documentação métodos XML que descreve as possíveis exceções.

Eu sou muito suspeito do NotSupportedException também ... Não suportado? O que? Se não for suportado, por que é parte de sua interface?

Pode haver razões milhões. Por exemplo, você pode introduzir nova versão de API e não querem / não pode suportar métodos antigos. Novamente, é muito melhor para ver exceção descritivo em vez de escavar em documentação ou depurar 3 código partido.

O uso principal para uma exceção NotImplementedException está em código de stub gerado: de que maneira você não se esqueça de implementá-lo !! Por exemplo, Visual Studio irá implementar explicitamente métodos / propriedades de uma interface com o corpo jogando um NotImplementedException.

Re NotImplementedException - isto serve alguns usos; que fornece uma única excepção de que (por exemplo) os testes de unidade pode bloquear para a obra incompleta. Mas também, ele realmente faz o que é diz: isso simplesmente não existe (ainda). Por exemplo, "mono" lança esta em todo o lugar por métodos que existem nas bibliotecas MS, mas ainda não foram escritas.

Re NotSupportedException - nem tudo está disponível. Por exemplo, muitas interfaces suportam um par "você pode fazer isso?" / "faça isso". Se o "você pode fazer isso?" retorna falso, é perfeitamente razoável para o "do presente" para jogar NotSupportedException. Exemplos disso podem ser IBindingList.SupportsSearching / IBindingList.Find() etc.

A maioria dos desenvolvedores da Microsoft estão familiarizados com padrões de projeto em que um NotImplementedException é apropriado. É bastante comum na verdade.

Um bom exemplo é uma Composto padrão, onde diversos objectos podem ser tratadas como uma única instância de um objecto. Um componente é usado como uma classe abstracta base para classes de folhas (correctamente) herdadas. Por exemplo, um arquivo e classe Directory pode herdar a partir da mesma classe base abstrata, porque são tipos muito semelhantes. Dessa forma, eles podem ser tratados como um único objeto (o que faz sentido quando você pensa sobre quais arquivos e diretórios são - em Unix por exemplo, tudo é um arquivo).

Assim, neste exemplo, haveria um método () para a classe Diretório GetFiles, no entanto, a classe File não iria implementar este método, porque não faz sentido fazê-lo. Em vez disso, você recebe um NotImplementedException, porque um arquivo não tem filhos da maneira um diretório faz.

Note que este não se limita a NET -. Você vai se deparar com esse padrão em muitas linguagens OO e plataformas

Por que você sente a necessidade de capturar cada exceção possível? Você envolver cada chamada de método com catch (NullReferenceException ex) também?

código Stub arremesso NotImplementedException é um espaço reservado, se torna para liberá-lo deve ser bug como NullReferenceException.

Eu acho que existem muitas razões pelas quais MS adicionados NotImplementedException ao quadro:

Como uma conveniência; uma vez que muitos desenvolvedores vai precisar dele durante o desenvolvimento, por que todo mundo tem que rolar seus próprios?
Assim que as ferramentas podem contar com a sua presença; por exemplo, comando do Visual Studio "Implementar Interface" gerar stubs método que NotImplementedException lance. Se não fosse no quadro, isso não seria possível, ou pelo menos um pouco estranho (por exemplo, poderia gerar o código que não compila até que você adicione seu próprio NotImplementedException)
Para encorajar uma "prática comum" consistente

frankodwyer pensa NotImplementedException como uma bomba-relógio em potencial. Eu diria que qualquer código inacabado é uma bomba-relógio, mas NotImplementedException é muito mais fácil de desarmar que as alternativas. Por exemplo, você poderia ter o seu servidor de compilação digitalizar o código fonte para todos os usos dessa classe, e relatá-los como avisos. Se você quer ser realmente proibi-lo, você pode até mesmo adicionar um pré-commit gancho para o seu sistema de controle de origem que impede checkin de tal código.

Claro, se você rolar o seu próprio NotImplementedException, você pode removê-lo a versão final para se certificar de que há bombas de tempo são deixados. Mas isto só irá funcionar se você usar sua própria implementação de forma consistente em toda a equipe, e você deve se certificar de que você não se esqueça de removê-lo antes de soltar. Além disso, você pode achar que você não pode removê-lo; talvez existam alguns usos aceitáveis, por exemplo, em testar código que não é fornecido aos clientes.

Não há realmente nenhuma razão para realmente captura a NotImplementedException. Quando atingido, ele deve matar seu aplicativo, e fazê-lo muito dolorosa. A única maneira de corrigi-lo não é por captura-lo, mas alterar seu código fonte (ou a implementação do método chamado, ou alterar o código de chamada).

Duas razões:

Os métodos são apagou durante o desenvolvimento e lançar a exceção para lembrar os desenvolvedores que a sua escrita de código não está terminado.
A implementação de uma interface subclasse que, pelo projeto, não implementa um ou mais métodos da classe base herdada ou interface. (Algumas interfaces são muito geral.)

Isso soa como um campo minado em potencial para mim. No passado distante, uma vez eu trabalhei em um sistema de rede legado que tinha sido executado sem parar durante anos e que caiu mais de um dia. Quando acompanhou o baixo problema, encontramos algum código que tinha claramente não foi concluído e que nunca poderia ter funcionado - literalmente, como o programador foi interrompido durante a codificação-lo. Era óbvio que este caminho de código em particular nunca tinha sido tomada antes.

A lei de Murphy diz que algo semelhante é apenas implorando para acontecer no caso de NotImplementedException. Concedido nestes dias de TDD etc, deve ser apanhada antes do lançamento, e pelo menos você pode grep código para essa exceção antes do lançamento, mas ainda assim.

Ao testar é difícil cobertura de garantia de todos os casos, e isso soa como ele faz o seu trabalho mais difícil, fazendo questões tempo de execução do que poderia ter sido questões tempo de compilação. (Eu acho que um tipo semelhante de 'dívida técnica' vem com sistemas que dependem fortemente de 'tipagem pato', embora reconheça que eles são muito úteis).

Você precisa desta excepção para interoperabilidade. É E_NOTIMPL . O blog ligado também mostra outras razões

Jogando NotImplementedException é a maneira mais lógica para o IDE para gerar compilar o código topo. Como quando você estender a interface e obter Visual Studio para stub-lo para você.

Se você fez um pouco de C ++ / COM, que existia lá também, exceto que ele era conhecido como E_NOTIMPL.

Não é um caso de uso válido para ele. Se você estiver trabalhando em um método particular de uma interface você quiser, código para compilar para que você pode depurar e testá-lo. De acordo com sua lógica seria necessário para remover o método fora da interface e comente não compilar o código topo. Esta é uma abordagem muito fundamentalista e enquanto ele tem o mérito, nem todo mundo vai ou deve aderir a essa. Além disso, na maioria das vezes você quer a interface para ser completa.

Ter um NotImplementedException bem identifica quais métodos não estão prontos ainda, no final do dia é tão fácil quanto apertar Ctrl+Shift+F encontrá-los todos, eu também sou certeza de que as ferramentas de análise de código estático vai buscá-lo também.

Você não está destinado ao código navio que tem exceção NotImplementedException. Se você acha que por não usá-lo você pode fazer seu código melhor, sair, mas há coisas mais produtivas que você pode fazer para melhorar a qualidade da fonte.

NotImplementedException

A exceção é lançada quando um método ou operação solicitada não está implementada.

Fazendo isso uma única exceção definida no núcleo .NET torna mais fácil de encontrar e erradicá-los. Se cada desenvolvedor deve criar seu próprio ACME.EmaNymton.NotImplementedException que seria mais difícil de encontrar todos eles.

NotSupportedException

A exceção é lançada quando um método invocado não é suportado.

Por exemplo, quando há uma tentativa de ler, procurar, ou gravar em um fluxo que não suporta a funcionalidade invocada.

por exemplo gerado iterators (usando a palavra chave yield) é-um IEnumerator, mas o método IEnumerator.Reset lança NotSupportedException.

De ECMA-335, a especificação CLI, specificialy os Tipos CLI Biblioteca, System.NotImplementedException, seção Comentários:

"Um certo número de tipos e construções, especificado noutra parte desta Norma, não são necessários de implementações da CLI que atendem apenas ao perfil Kernel. Por exemplo, o conjunto de recursos de ponto flutuante consiste dos tipos de dados de ponto flutuante Sistema .Single e System.Double. Se o suporte para estes é omitida a partir de uma aplicação, qualquer tentativa para fazer referência a uma assinatura que inclui o ponto flutuante tipos de dados resulta em uma exceção do tipo System.NotImplementedException. "

Assim, a exceção é destinado para implementações que implementam somente perfis de conformidade mínimos. O perfil mínimo exigido é o perfil do Kernel (veja ECMA-335 4ª edição - Partition IV, seção 3), que inclui o BCL, razão pela qual a exceção é incluído no "API core", e não em algum outro local <. / p>

Usando a exceção para denotar métodos stubbed, ou para métodos de design gerado falta de implementação é não compreender a intenção da exceção.

Quanto ao porquê de esta informação não está incluído na documentação do MSDN para a implementação do CLI do MS está além de mim.

Eu não posso garantir para NotImplementedException (I maioria deles concorda com o seu ponto de vista) mas eu tenho NotSupportedException usado extensivamente na biblioteca central que usamos no trabalho. O DatabaseController, por exemplo, permite que você crie um banco de dados de qualquer tipo suportado, em seguida, usar a classe DatabaseController em todo o resto do seu código sem se importar muito com o tipo de debaixo do banco de dados. Bastante coisas básicas, certo? Onde NotSupportedException vem a calhar (e onde eu teria usado a minha própria implementação se não se existir) é duas instâncias principais:

1) A migração de uma aplicação para um banco de dados diferente É muitas vezes argumentado isso raramente, ou nunca, acontece ou é necessário. Bullsh * t. Sair mais.

2) O mesmo banco de dados, driver diferente Mais recente exemplo disso foi quando um cliente que usa uma aplicação apoiada pelo acesso atualizado a partir de WinXP para Win7 x64. Sendo nenhum driver JET de 64 bits, o seu TI cara instalou o AccessDatabaseEngine vez. Quando nosso aplicativo caiu, poderíamos facilmente ver a partir do log foi DB.Connect bater com NotSupportedException - que foram rapidamente capaz de endereço. Outro exemplo recente foi um dos nossos programadores tentando usar transações em um banco de dados Access. Apesar de Acesso suporta transações, nossa biblioteca não suporta transações de acesso (por razões fora do âmbito deste artigo). NotSupportedException, é sua hora de brilhar!

3) funções genéricas Eu não posso pensar em um conciso "por experiência" exemplo aqui, mas se você pensar sobre algo como uma função que adiciona um anexo a um e-mail, você quer que ele seja capaz de levar alguns arquivos comuns, como JPEGs, qualquer coisa derivada de vários transmitir classes, e praticamente qualquer coisa que tem um método ".ToString". Para a última parte, você certamente não pode dar conta de todo o tipo possível para que você torná-lo genérico. Quando um usuário passa OurCrazyDataTypeForContainingProprietarySpreadsheetData, uso de reflexão para testar a presença de um método ToString e NotSupportedException de retorno para indicar falta de apoio a esse tipos de dados que não suportam ToString.

NotSupportedException não é por qualquer meio um recurso crucial, mas é algo que eu me encontro com muito mais como eu trabalho em projetos maiores.

Vamos dizer que você tem esse método no seu código de produção

public void DoSomething()

Qual deles você tomar se você quer deixá-lo mais tarde para ser concluído?

public void DoSomething()
{
}

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

Eu certamente tomar a segunda. Juntamente com Elmah ou qualquer erro de registro mecanismo você (implementado como um aspecto em toda a sua aplicação). Juntamente com log / exceção filtragem de gatilho para a notificação de e-mail de erro critial quando se é pego.

O argumento de que NotImplementedException == inacabada não é correto também. (1) de travamento de métodos unimplemented deve ser deixado para testes de testes e / ou de integração da unidade. Se você tem 100% de cobertura (que agora você deve fazer, com tantas muitas ferramentas de simulação / stub / geração de código) sem NotImplementedException, quais são suas preocupações? geração (2) código. simples Plain. Novamente, se eu gerar o código, e apenas metade utilização do código gerado, por que não tenho NotImplementedException no resto do stub gerado?

É como dizer código não deve compilar a menos que cada entrada anulável devem ser verificados / manuseado por nulo. (AKA o erro de trilhões de dólares, se não mais). Língua deve ser flexível, enquanto os testes / contratos deve ser sólido.

Raramente eu usá-lo para fixação interface. Suponha que você tenha uma interface que você precisa para cumprir, mas determinado método nunca será chamado por ninguém, então se ater apenas um NotImplementedException e se alguém o chama eles vão saber que eles estão fazendo algo errado.

NotImplementedException é jogado por algum método de .NET (veja o analisador C # no código DOM que não é implementada, mas a exist método!) Você pode verificar com este Microsoft.CSharp.CSharpCodeProvider.Parse método

Ambos são hacks para dois problemas comuns.

NotImplementedException é uma solução para os desenvolvedores que estão arquitetura astronautas e como para escrever o API primeiro, código posteriores. Obviamente, uma vez que este não é um processo incremental, você não pode implementar tudo de uma vez e, portanto, você quer fingir que você está semi-feito jogando NotImplementedException.

NotSupportedException é um hack em torno da limitação dos sistemas do tipo, como os encontrados em C # e Java. Nestes sistemas do tipo, você diz que um retângulo 'é uma' Forma sse Retângulo herda todas as características formas (incl. De membros + funções variáveis). No entanto, na prática, isso não é verdade. Por exemplo, um quadrado é um retângulo, mas a Square é uma restrição de um retângulo, não uma generalização.

Então, quando você quer herdar e restringir o comportamento da classe pai, você joga NotSupported em métodos que não fazem sentido para a restrição.

E sobre protótipos ou projetos inacabados?

Eu não acho que isso é uma péssima idéia usar uma exceção (embora eu usar um messagebox nesse caso).

Bem, eu concordo um pouco. Se uma interface tem sido feito de maneira tal que nem toda classe pode implementar todas as partes dele, que deveria ter sido discriminado na minha opinião.

Se IList pode ou não pode ser modificado, ele deveria ter sido dividido em dois, um para a parte unmodifiable (getters, pesquisa, etc.), e um para a parte modificável (setters, adicionar, remover, etc. ).

Eu tenho algumas NotImplementedExceptions no meu código. Muitas vezes se trata de parte de uma interface ou classe abstrata. Alguns métodos que eu sinto que pode precisar no futuro, elas fazem sentido como sendo parte da classe, mas eu simplesmente não querem tomar o tempo para adicionar a menos que eu realmente precisar dele. Por exemplo, eu tenho uma interface para todos os tipos individuais de estatísticas no meu jogo. Um desses tipos é um ModStat, que é a soma da estatística de base mais todos os modificadores (isto é, armas, armaduras, períodos). Minha interface de status tem um evento OnChanged, mas meu ModStat funciona calculando a soma de todas as estatísticas que faz referência a cada vez que ele é chamado. Então, ao invés de ter a sobrecarga de uma tonelada de eventos ModStat.OnChange sendo levantada cada vez que uma estatística mudanças, eu só tenho um NotImplementedException lançada se alguém tentar adicionar / remover um ouvinte para OnChange.

.NET línguas são todos sobre a produtividade, então por que gastar o seu tempo de codificação algo que você não vai mesmo usar?

Aqui está um exemplo: Em Java, quando você implementar a Iterator interface, você tem que substituir os métodos hasNext() e next() óbvio, mas há também delete(). Em 99% dos casos de uso que eu tenho Eu não preciso isso, então eu apenas jogar um NotImplementedException. Isto é muito melhor do que o silêncio não fazer nada.

O NotImplementedException só existe para facilitar o desenvolvimento. Imagine que você começar a implementar uma interface. Você gostaria de ser capaz de, pelo menos, de construção quando você está feito implementando um método, antes de passar para a próxima. Stubbing os métodos NotImplemented com NotImplementedExceptions é uma ótima maneira de viver código inacabado que é super fácil de detectar mais tarde. Caso contrário, você corre o risco de rapidamente implementar algo que você pode esquecer de corrigir.

Se você não quiser usá-lo, em seguida, simplesmente ignorá-la. Se você tem um bloco de código cujo sucesso depende de cada pedaço dele ter sucesso, mas pode falhar no meio, em seguida, sua única opção é pegar o Exception base e reverter o que precisa ser revertida. Esqueça NotImplementedException. Não poderia haver toneladas de exceções lançadas, como MyRandomException e GtfoException e OmgLolException. Depois de inicialmente escrever o código que eu poderia vir e jogar outro tipo de exceção da API que você está chamando. Um que não existia quando você escreveu seu código. Lidar com as que sabem como lidar com e rollback para quaisquer outros ou seja, catch(Exception). É muito simples, eu acho ... acho que é vem a calhar também. Especialmente quando você está tentando fantasia coisas com a linguagem / framework que ocasionalmente forçar as coisas em cima de você.

Um exemplo que eu tenho é de serialização. Eu adicionei propriedades em minha biblioteca .NET que não existem no banco de dados (por exemplo, wrappers convenientes mais propriedades "burras" existentes, como uma propriedade FullName que combina FirstName, MiddleName e LastName). Então eu quero serializar esses tipos de dados para XML para enviá-los ao longo do fio (por exemplo, a partir de uma aplicação ASP.NET para JavaScript), mas o quadro de serialização única serializa propriedades públicas com ambos os get e set acessores. Eu não quero que você seja capaz de definir FullName porque então eu teria que analisá-lo para fora e pode haver algum formato imprevisto que eu erroneamente analisar e integridade de dados sai pela janela. É mais fácil simplesmente usar as propriedades subjacentes para isso, mas uma vez que a linguagem e API me obrigar a ter um acessor set, eu vou jogar um NotImplementedException (Eu não estava ciente de NotSupportedException até que eu li esta discussão, mas de qualquer um funciona) de modo que se algum programador pela estrada faz tentar definir FullName ele vai encontrar a exceção durante o teste e perceber seu erro.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow