Por que os erros são nomeados como "Exceção", mas não como "Erro" nas linguagens de programação?

Eu tenho pensado nisso por um bom tempo, na verdade. Eu não sou um falante nativo de inglês, mas ainda tenho anos de experiência em programação e sempre me perguntei isso. Por que é nomeado como exceção, mas não como erro, pois são erros.

Poderia ser em PageNotFoundErrorvez de PageNotFoundException.

Eles não precisam ser erros. O fato de a página não estar lá pode ser apenas um fato interessante, e não um erro real. Eles parecem se acostumar como erros quase o tempo todo, admito. Mas, às vezes, eles são usados ​​para romper loops ou informar que uma string não é um número válido. Eles podem ser usados ​​para manter e retornar grandes quantidades de dados úteis - como parte de um retorno bastante normal. (Alguns idiomas são um pouco lentos com suas exceções, nesse caso, lançá-los com frequência é uma má idéia.) Em teoria, de qualquer forma, uma exceção significa apenas "não faça um retorno normal, suba a pilha de chamadas até encontrar alguém interessado nisso."

Mesmo uma exceção de ponteiro nulo pode não significar muito para você. Você chama o código de outra pessoa e, em seguida, captura uma exceção de ponteiro nulo porque sabe que ela pode explodir, imprime uma mensagem dizendo de quem é a culpa e continua e executa seu trabalho.

O mecanismo de exceções nem sempre é usado para sinalizar erros. Exceções são lançadas fora das situações comuns que exigem um caminho de código separado para serem processadas, incluindo erros. Por exemplo, um usuário que fornece o nome de um arquivo que não existe, ou digita uma letra em vez de um dígito em um campo numérico, são situações excepcionais que requerem tratamento especial, mas não são erros.

Em alguns ambientes de programação, como Java, Errorobjetos especiais são fornecidos para relatar "erros verdadeiros", situações que um aplicativo razoável não deve tentar manipular. Esses objetos são entregues usando o mesmo mecanismo usado para fornecer exceções, mas eles têm um significado especial de sinais de situações irrecuperáveis.

Não tenho uma pesquisa etimológica sobre as origens disso, mas posso entender que o uso do termo "Erro" pode não ser preciso em todas as situações; também como quase o SharepointMaster mencionou, é melhor pensar no erro e na exceção lançados como entidades separadas.

Quando você está em uma linguagem de programação de alto nível, faz sentido supor que uma exceção é sempre causada por um erro, embora eu concorde também com o dasblinkenlight que, mesmo assim, uma exceção nem sempre é a consequência de um erro. Por exemplo, eu uso exceções para encerrar threads de forma colaborativa.

A primeira vez que vi o termo "exceção" foi no manual de montagem 80386. Lembro que, quando vi, pareceu instantaneamente natural para mim. Chamar isso de erro não seria correto, porque não há erros no Assembly; existem simplesmente condições com as quais o processador não consegue lidar (se isso é um erro - do programador, do usuário ou do sistema - bem, o processador é completamente independente disso). Não sei se a Intel realmente originou o termo ou não, mas talvez ...

O Commonly Exception é usado para nomear um evento que não está correto, mas pode ser recuperado, como uma out_of_rangeexceção no C ++, lançada ao acessar um elemento em um vetor ou matriz que não existe. Claramente, esse evento não está correto, mas isso não deve significar que todo o programa trava.

Por outro lado, os erros geralmente são usados ​​para nomear algo que deve travar tudo, algo como um estouro de pilha é um exemplo de um evento que deve encerrar o programa, pois o programa não pode lidar com isso internamente. Em outras palavras: um erro é grave, enquanto uma exceção é comparativamente menor.

Eu acho que isso tem mais a ver com a "evolução" do tratamento de erros. Com as linguagens C / C ++ (antes da adição do tratamento de exceções), se uma função falhar, a única maneira de informar é através do valor de retorno (por exemplo, HRESULTno win32). Normalmente, você acabava pegando códigos de saída de cada chamada de função e fazia uma verificação. Essa abordagem torna o código mais confuso. E muitas vezes os desenvolvedores evitam adicionar essas verificações por preguiça.

Com a introdução do tratamento de exceções, os desenvolvedores agora tinham duas opções para gerar um erro. Portanto, a palavra "exceção" foi usada para distinguir erros dos erros "status de saída". Após um período de tempo, o tratamento de exceções se tornou uma maneira popular de propagar erros porque o código é muito mais fácil de ler, manter e pode haver um único local onde você pode ter uma lógica de tratamento de erros.

No Python, eles são nomeados como ABCError Por exemplo: KeyError, IndexError

http://docs.python.org/library/exceptions.html

Então eu acho que depende do idioma que você usa.

Quando ocorre um erro, o sistema ou o aplicativo em execução no momento o relata lançando uma exceção que contém informações sobre o erro. Uma vez lançada, uma exceção é manipulada pelo aplicativo ou pelo manipulador de exceção padrão.

Um erro gera uma exceção que detalha o erro; portanto, nem tudo é um erro, se isso faz sentido;), por exemplo, uma exceção não simplificada não deve ser um erro, mas gera uma exceção.

http://msdn.microsoft.com/en-us/library/system.exception.aspx

Na programação iOS / Mac, temos Exceções e Erros em um único idioma.

Pelo menos nesse ambiente, uma exceção é "não recuperável", enquanto um erro é "recuperável".

Por exemplo:

• se você tiver uma matriz com 10 itens e tentar acessar o item no índice 30 - isso será uma exceção. Você cometeu um erro na sua programação.
• se você tentar baixar um URL, mas não houver conexão com a Internet, isso é esperado e você deverá apresentar algum tipo de mensagem ao usuário.

As exceções normalmente travam seu aplicativo, enquanto os erros geralmente retornam nile um objeto de erro (retornado como parâmetro pelo método de referência). Você pode capturar exceções com um bloco try / catch / finalmente, mas é recomendável nunca usar esse recurso de idioma - se for possível recuperar de uma exceção de alguma forma, você não deve lançar nenhuma exceção (você deve retornar um objeto de erro).

Um erro é algo que deu errado na execução do programa. Muitas vezes, isso é resolvido gerando uma exceção , mas

• não há nada que force um programador a lidar com um erro gerando uma exceção e
• não há nada que force um programador a gerar exceções apenas no caso de um erro.

Erro é um conceito semântico : é aplicado pelo programador ou usuário, que chega ao programa com expectativas, para descrever a diferença entre suas expectativas e a realidade. Somente uma pessoa pode dizer se uma rotina está em um estado de erro ou não.

Uma exceção é um conceito sintático : é algo no próprio programa, independente das expectativas de qualquer pessoa sobre o que esse programa deve fazer. Uma rotina cria ou não gera uma exceção, independentemente do que alguém pensa.

Exceções e erros são diferentes.

Exceções são situações que um programa pode superar, como digamos que você tenta abrir um arquivo e ele não existe, enquanto erros são situações em que um programa não pode fazer nada, como uma falha de disco ou RAM.

Gerar e manipular exceções são recursos de fluxo de controle e o nome da exceção deve seguir o uso pretendido. O criador do código e da API deve encontrar esquemas de nomeação bons e consistentes.

Portanto, a resposta para sua pergunta é: depende do contexto e da perspectiva.

As exceções evoluíram como uma generalização de erros. A primeira linguagem de programação a incluir um mecanismo de exceção foi o Lisp no início dos anos 70. Há um bom resumo em A Pattern of Language Evolution, de Gabriel e Steele. Exceções (que ainda não foram chamadas de exceções) surgiram da necessidade de especificar o comportamento de um programa se ocorrer um erro. Uma possibilidade é interromper o programa, mas isso nem sempre é útil. As implementações do Lisp tradicionalmente tinham uma maneira de inserir o depurador em um erro, mas às vezes os programadores queriam incluir a manipulação de erros em seu programa. Portanto, as implementações do Lisp dos anos 60 tinham uma maneira de dizer "faça isso, e se ocorrer um erro, faça isso". Originalmente, os erros vinham de funções primitivas, mas os programadores acharam conveniente acionar deliberadamente um erro para pular parte do programa e pular para o manipulador de erros.

Em 1972, a forma moderna de tratamento de exceções no Lisp apareceu no MacLisp: throwe catch. O Grupo de Preservação de Software lista muito material das implementações iniciais do Lisp, incluindo The MACLISP Reference Manual Revision 0, de David Moon . As primitivas catche throwestão documentadas em §5.3 p.43.

catché a função LISP para executar saídas não locais estruturadas. (catch x)avalia xe retorna seus valores, exceto que, se durante a avaliação de x (throw y)deve ser avaliado, catchretorna imediatamente ysem avaliação adicional x.

catchtambém pode ser usado com um argumento econd, não avaliado, que é usado como uma marca para distinguir entre capturas aninhadas. (…)

throwé usado catchcomo um mecanismo de saída não-local estruturado.

(throw x)avalia xe lança o valor de volta ao mais recente catch.

(throw x <tag>)lança o valor de xvolta para o mais recente catchrotulado com <tag>ou sem rótulo .

O foco está no fluxo de controle não - local . É uma forma de goto (apenas para cima), que também é chamada de salto . A metáfora é que uma parte do programa lança o valor para retornar ao manipulador de exceções, e o manipulador de exceções captura esse valor e o retorna.

Atualmente, a maioria das linguagens de programação compacta a tag e o valor em um objeto de exceção e combina o mecanismo de captura com um mecanismo de manipulação.

Exceções não são necessariamente erros. Eles são uma maneira de sair de um bloco de código e dos blocos circundantes, escapando até que um manipulador da exceção seja atingido. Se uma coisa dessas é considerada um "erro" no sentido intuitivo é subjetivo.

Alguns idiomas fazem uma distinção entre os termos "erro" e "exceção". Por exemplo, alguns dialetos Lisp têm throwque gerar uma exceção (fluxo de controle para usuários, destinado a executar uma saída não local de uma maneira que não indique que algo deu errado)) e signalgerar um erro (que indica que algo deu "errado" e pode desencadear um evento de depuração).

Você descobrirá que ele é interpretado de maneira diferente em diferentes implementações de linguagem de programação. Como o dasblinkenlight disse, esse é um ponto de vista java de ter uma demarcação entre Erro e Exceção. Em muitas linguagens de programação, as exceções são violações que podem ser tratadas ou permitidas a serem borbulhadas para passar para o módulo de código mais alto possível. Erros geralmente são situações em que o contêiner de tempo de execução do seu idioma lida (e muitos casos interrompem a execução).

Um erro é sempre um erro. Uma exceção é um erro no contexto atual. Ou seja, uma exceção é sensível ao contexto. Um exemplo de exceção seria adicionar um ascii "a" a um número inteiro "1". Um erro pode ser algo como usar um operador indefinido como "+!" na maioria dos idiomas.

Alguns idiomas permitem que você defina seu caminho para sair da situação, se é realmente isso que você deseja fazer.