Por que muitas mensagens de exceção não contêm detalhes úteis?

Eu não tenho um excesso de experiência em C #, ou C ++ especificamente, mas posso dizer-lhe isto - exceções escritas pelo desenvolvedor 9 em 10 vezes são mais úteis do que qualquer exceção genérica que você irá encontrar, ponto final.

Idealmente, sim, uma exceção genérica indicará exatamente por que o erro ocorreu e você poderá corrigi-lo com facilidade, mas, realisticamente, em aplicativos grandes com várias classes que podem lançar uma ampla variedade de tipos diferentes de exceções ou o tipo de exceções same , é sempre mais valioso gravar sua própria saída para retorno de erro do que depender da mensagem padrão.

É assim que deve ser, porque, como muitas pessoas apontaram, alguns aplicativos não querem lançar uma mensagem de erro que eles não querem que o usuário veja, por motivos de segurança ou para evitar confundi-los.

Em vez disso, você deve prever em seu design quais tipos de erros podem ser lançados em seu aplicativo (e sempre haverá erros) e gravar mensagens de erro que ajudem a identificar o problema.

Isso nem sempre ajuda você, pois nem sempre é possível prever qual mensagem de erro será útil, mas é o primeiro passo para entender melhor sua própria aplicação a longo prazo.

A questão é especificamente perguntar por que tantas exceções lançadas por "componentes do sistema" (também conhecidas como classes de biblioteca padrão) não contêm detalhes úteis.

Infelizmente, a maioria dos desenvolvedores não escreve os componentes principais em bibliotecas padrão, nem documentos de design detalhados ou outras justificativas de design são necessariamente tornadas públicas. Em outras palavras, podemos nunca saber com certeza.

No entanto, existem dois pontos-chave para ter em mente o motivo pelo qual informações detalhadas sobre exceções podem não ser desejáveis ou importantes:

1. Uma exceção pode ser usada pelo código de chamada de qualquer maneira: uma biblioteca padrão não pode colocar restrições sobre como a exceção é usada. Especificamente, pode ser exibido para o usuário. Considere um índice de matriz fora dos limites: isso pode fornecer informações úteis para um invasor. O designer de idiomas não tem ideia de como um aplicativo usará a exceção gerada ou mesmo o tipo de aplicativo (por exemplo, aplicativo da Web ou desktop), portanto, deixar de fora as informações pode ser mais seguro do ponto de vista da segurança.

2. Exceções não devem ser exibidas para o usuário. Em vez disso, exiba uma mensagem de erro amigável e registre a exceção em um local que o invasor não tenha acesso (se aplicável). Depois que o erro é identificado, um desenvolvedor deve depurar o código, inspecionando quadros de pilha e caminhos lógicos. Neste ponto, o desenvolvedor tem mais informações do que uma exceção poderia esperar ter.

Tenho escrito software e suportado os resultados de outros softwares por mais de 30 anos e, pessoalmente, a qualidade atual de uma mensagem de exceção não tem praticamente nada a ver com segurança, independentemente de como os resultados finais se encaixaram. seu modelo do universo, muito mais a ver com o fato de tantas pessoas em nossa indústria serem originalmente autodidatas, e elas nunca incluíram lições em comunicações. Talvez se nós forçássemos todos os novos codificadores em uma posição de manutenção por alguns anos, onde eles tivessem que lidar com o que estava errado, eles entenderiam a importância de pelo menos alguma forma de precisão.

Recentemente, em um aplicativo sendo reconstruído, foi tomada a decisão de que os códigos de retorno se encaixariam em um dos três grupos:

• 0 a 9 seria sucesso através do sucesso com adicionais em formação.
• 10 a 99 seria não fatal (recuperável) erros e
• 101 a 255 seriam erros fatais.

(100 foi por algum motivo deixado de fora)

Em qualquer fluxo de trabalho específico, nosso pensamento foi reutilizado ou código genérico usaria retornos genéricos (> 199) para erros fatais, deixando-nos com 100 erros fatais possíveis para um fluxo de trabalho. Com dados ligeiramente diferenciados na mensagem, erros como arquivos não encontrados podem usar o mesmo código e se diferenciar com as mensagens.

Quando o código voltou dos contratantes, você não acreditaria em nossa surpresa quando praticamente TODOS OS ERROS FATAIS ÚNICOS eram código de retorno 101.

Tudo o que considerei, acho que a resposta à sua pergunta é que as mensagens são tão insignificantes, porque quando originalmente criadas, elas eram espaços reservados para os quais ninguém retornava. Eventualmente, as pessoas descobriram como consertar os problemas não por causa das mensagens, mas por revelá-las.

Desde aquela época, as pessoas autodidatas simplesmente nunca tiveram um bom exemplo do que uma exceção deveria conter. Acrescente a isso que mais usuários não leiam as mensagens, muito menos tentem passá-lo para o suporte (vi mensagens de erro que foram cortadas e coladas pelo usuário que foram então editadas antes de serem enviadas com o comentário posterior que parecia muita informação e eu não poderia querer tudo, então eles removeram aleatoriamente um monte dela.

E vamos enfrentá-lo, com muitos (não todos, mas muitos) da próxima geração de codificadores, se é mais trabalho e não adiciona flash, apenas não vale a pena ...

Última observação: Se uma mensagem de erro incluir um erro / código de retorno, parece-me que em algum lugar dos módulos executados deve haver uma linha que leia algo como "se a condição retornar o valor de código" e a condição deve informar o motivo o código de retorno ocorreu. Isso parece uma abordagem lógica simples, mas, para minha vida, apenas tente fazer com que a Microsoft informe o que aconteceu quando uma atualização do Windows falhou no CÓDIGO 80241013 ou em algum outro identificador muito exclusivo. Meio triste, não é?

Embora eu concorde que as exceções devem conter o máximo de informações possível, ou pelo menos menos genéricas. Na tabela não encontrada, o nome da tabela seria bom.

Mas você sabe mais sobre o que estava tentando fazer no local no código em que recebeu a exceção. Embora muitas vezes você realmente não possa fazer muito para corrigir a situação quando algo dá errado em uma biblioteca fora do seu controle, você pode adicionar informações muito mais úteis sobre em que situação algo deu errado.

No caso da tabela não encontrada, não será muito útil se você disser que a tabela que não pode ser encontrada se chama STUDENTS, porque você não tem essa tabela, e essa string não está em lugar nenhum do seu código.

Mas se você pegar a exceção e relançá-la com a instrução SQL que você estava tentando executar, você ficará melhor, já que você tentou inserir um registro com o campo de nome sendo Robert '); DROP TABLE STUDENTS; (Há sempre um xkcd!)

Assim, para combater as exceções menos informativas: tente-retraia-receba com mais informações específicas para o que você estava tentando fazer.

Eu provavelmente deveria acrescentar, para que isso seja mais uma resposta sobre o porquê da pergunta, que uma razão provável pela qual o foco dos criadores das bibliotecas não tem sido tornar as mensagens de exceção melhores, é que elas não sei porque algo foi tentado que falhou, que a lógica está no código de chamada.

Para dar uma resposta ligeiramente diferente: O código incorreto provavelmente foi feito para a especificação:

• A função recebe X e retorna Y
• Se X for inválido, ative a exceção Z

Adicione a pressão para entregar exatamente à especificação (por medo de ser rejeitado em revisão / teste) em tempo mínimo e com o mínimo de barulho, então você tem a sua receita para uma exceção de biblioteca totalmente compatível e inútil.

As exceções têm um custo específico de linguagem e implementação.

Por exemplo, as exceções do C ++ são necessárias para destruir todos os dados existentes entre o quadro de chamada de lançamento e o quadro de chamada de captura, e isso é caro. Portanto, os programadores não desejam usar muito as exceções.

No Ocaml, o lançamento de exceção é quase tão rápido quanto um C setjmp (seu custo não depende do número de quadros de chamada percorridos), portanto os desenvolvedores podem usá-lo muito (mesmo para não-excepcionais, muito comuns casos). Em contraste, as exceções do C ++ são pesadas o suficiente, então você provavelmente não as usará muito como faria no Ocaml.

Um exemplo típico é uma pesquisa ou exploração recursiva que pode ser "interrompida" em uma recursão bastante profunda (por exemplo, localizar uma folha em uma árvore ou uma função de unificação). Em alguns idiomas, é mais rápido (de forma mais idiomática) propagar essa condição para todos os chamadores. Em outros idiomas, lançar uma exceção é mais rápido.

Portanto, dependendo da linguagem (e dos hábitos dos desenvolvedores que a usam), uma exceção pode conter muitos detalhes úteis ou, pelo contrário, ser usada como um salto rápido não local e transportar apenas os dados muito úteis. / p>     

O que faz você pensar que o valor do índice ou o intervalo necessário ou o nome da tabela é um detalhe útil, para uma exceção?

As exceções não são um mecanismo de tratamento de erros; eles são um mecanismo recuperação .

O ponto de exceção é borbulhar até o nível de código que pode manipular a exceção. Onde quer que esse nível esteja, você tem as informações necessárias, ou não é relevante. Se houver informações que você precisa, mas não tem acesso imediato , você não está lidando com a exceção no nível apropriado.

A única vez que posso pensar em onde informação extra poderia ser útil é no nível superior absoluto da sua aplicação, onde você falha e emite um dump de erro; mas não é o trabalho da exceção acessar, compilar e armazenar essas informações.

Eu não estou dizendo que você pode simplesmente colocar "throw new Exception" em todos os lugares e chamá-lo de bom, é possível escrever más exceções. Mas incluir informações irrelevantes não é necessário para usá-las corretamente.