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

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 com erros quase o tempo todo, eu admito. Mas às vezes eles estão acostumados a sair de loops, ou deixar você saber que uma string não é um número válido. Eles podem ser usados para armazenar e retornar grandes quantidades de dados úteis - como parte de um retorno razoavelmente normal. (Algumas linguagens são um pouco lentas com suas exceções, nesse caso, lançá-las frequentemente é uma má idéia.) Em teoria, uma exceção significa apenas "não fazer um retorno normal, subir a pilha de chamadas até encontrar alguém interessado neste. "

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, pega uma exceção de ponteiro nulo porque sabe que pode explodir, imprimir uma mensagem dizendo de quem é a falha e continuar e fazer seu trabalho.

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

Em alguns ambientes de programação, como o Java, o Error objetos 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 entregar exceções, mas eles têm um significado especial de sinais de situações irrecuperáveis.

Eu não tenho uma pesquisa etimológica sobre as origens disso, mas posso entender que usar o termo "Erro" pode não ser preciso em todas as situações; Também como quaseSharepointMaster mencionado, é melhor pensar no erro e a exceção lançada 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 dasblinkenlight que mesmo assim uma exceção nem sempre é a conseqüência de um erro. Eu, por exemplo, uso exceções para finalizar os tópicos de forma colaborativa.

A primeira vez que vi o termo "exceção" estava no manual de montagem do 80386. Lembro-me de quando vi que parecia instantaneamente natural para mim. Chamar isso de um erro não seria correto, porque não há erros no Assembly; simplesmente há 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 agnóstico a isso). Eu não sei se a Intel realmente originou o termo ou não, mas talvez ...

Comumente, Exceção é usada para nomear um evento que não está correto, mas pode ser recuperado, como uma exceção out_of_range em C ++, que é lançada ao acessar um elemento em um vetor ou matriz que não existe. Claramente, tal evento não está correto, mas isso não deve significar que todo o seu programa falhe.

Por outro lado, 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 terminar o programa, pois o programa não pode manipulá-lo internamente. Em outras palavras: um erro é maior, enquanto uma exceção é comparativamente menor.

Acho que isso tem mais a ver com "evolução" do tratamento de erros. Com linguagens C / C ++ (antes da manipulação de exceções ser adicionada), se uma função falhava, a única maneira de informar era através do valor de retorno (por exemplo, HRESULT no win32). Então, normalmente você acaba pegando os códigos de saída de cada chamada de função e faz uma checagem. Essa abordagem torna o código mais confuso. E muitas vezes os desenvolvedores simplesmente evitam adicionar essas verificações à preguiça.

Com a introdução do tratamento de exceções, os desenvolvedores agora tinham duas opções para gerar um erro. Assim, a palavra "exceção" foi usada para distinguir erros de erros de "status de saída". Após um período de tempo, o tratamento de exceções tornou-se 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ê possa ter uma lógica de tratamento de erros.

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

link

Então, acho que depende da linguagem que você usa.

Quando ocorre um erro, o sistema ou o aplicativo atualmente em execução o reporta, lançando uma exceção contendo 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 exibe uma exceção que detalha o erro, portanto nem tudo é um erro que é uma exceção se isso fizer sentido;), por exemplo, uma exceção não minimizada não deve ser um erro, mas gera uma exceção.

link

Na programação do 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 em sua programação.
• se você tentar baixar um URL, mas não houver conexão com a Internet, isso é esperado e deverá apresentar algum tipo de mensagem ao usuário.

As exceções geralmente travam seu aplicativo, enquanto os erros geralmente retornam nil e um objeto de erro (retornado como um parâmetro pelo método de referência). Você pode capturar exceções com um bloco try / catch / finally mas é recomendado nunca usar este recurso de linguagem - se é possível se recuperar de uma exceção de qualquer forma, então você não deveria estar lançando uma exceção (você deve retornar um objeto de erro).

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

• não há nada que force um programador a manipular um erro, levantando uma exceção e
• não há nada que force um programador a criar exceções apenas no caso de um erro.

O 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 realidade. Somente uma pessoa pode dizer se uma rotina está em 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 o programa deve fazer. Uma rotina faz ou não 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 se você tentasse abrir um arquivo e ele não existisse, enquanto erros são situações que um programa não pode fazer nada, como uma falha de disco ou uma falha de RAM.

Aumento e tratamento de exceções são recursos de fluxo de controle e o nome da exceção deve seguir o uso pretendido. O designer de código e API deve encontrar esquemas de nomenclatura bons e consistentes.

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

Exceções evoluíram como uma generalização de erros. A primeira primeira linguagem de programação a incluir um mecanismo de exceção foi Lisp no início dos anos 70. Há um bom resumo em Um padrão de evolução da linguagem por Gabriel e Steele . Exceções (que ainda não eram chamadas de exceções) surgiram da necessidade de especificar o comportamento de um programa se um erro ocorrer. Uma possibilidade é parar 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 o tratamento de erros em seu programa. Então, as implementações 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 desencadear deliberadamente um erro para pular alguma 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: throw e catch . O Grupo de Preservação de Software lista muito material sobre as primeiras implementações de Lisp, incluindo O Manual de Referência MACLISP Revisão 0, de David Moon . As primitivas catch e throw estão documentadas em § 5.3 p.43.

catch is the LISP function for doing structured non-local exits. (catch x) evaluates x and returns its values, except that if during the evaluation of x (throw y) should be evaluated, catch immediately returns y without further evaluating x.

catch may also be used with a econd argument, not evaluated, which is used as a tag to distinguish between nested catches. (…)

throw is used with catch as a structured nonlocal exit mechanism.

(throw x) evaluates x and throws the value back to the most recent catch.

(throw x <tag>) throws the value of x back to the most recent catch labelled with <tag> or unlabelled.

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

A maioria das linguagens de programação hoje empacota 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 adjacentes, escapando até que um manipulador para a exceção seja atingido. Se tal coisa é considerada um "erro" no sentido intuitivo é subjetivo.

Algumas linguagens fazem uma distinção entre os termos "erro" e "exceção". Por exemplo, alguns dialetos Lisp têm throw para 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 indica que algo foi "errado") e signal para aumentar um erro (que indica que algo deu errado e pode desencadear um evento de depuração).

Você vai encontrá-lo diferentemente interpretado em diferentes implementações de linguagem de programação. Como dasblinkenlight disse que é 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 manipuladas ou permitidas para serem transferidas para o módulo de código mais alto possível. Geralmente, os erros são situações em que o contêiner de tempo de execução da sua linguagem manipula (e muitos casos apenas 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 uma exceção seria adicionar um ascii "a" a um inteiro "1". Um erro pode ser algo como usar um operador indefinido como "+!" na maioria das línguas.

Algumas línguas permitirão que você defina o caminho para sair da situação, se isso é realmente o que você quer fazer.