Segundo, estava pensando se alguém sabia qual era a diferença entre exceções (no domínio do fluxo de controle de exceções) e Exceções (como as usadas em Java).
Mas eles existem para proteger basicamente o sistema contra falhas, encerrando o programa do usuário?
Respostas:
Existem exceções para permitir o tratamento de exceções , o que pode evitar falhas, mas geralmente impede o comportamento indesejado ou imprevisível do sistema. Por exemplo, se a conexão do meu programa com um banco de dados atingir o tempo limite, geralmente ele não trava o sistema, mas se eu estivesse dependendo dos dados do banco de dados, uma exceção poderia me permitir tratar essa situação sem dados de maneira diferente do normal.
Digamos que, por padrão, meu programa exibe uma página de dados com base no que foi retornado do banco de dados - bem, porcaria, não tenho dados. Em vez de apresentar uma visão confusa ou continuar uma operação potencialmente inválida, posso capturar essa exceção e retornar a um banco de dados diferente, ler dados locais, solicitar dados ao usuário ou retornar o usuário ou sistema a um estado seguro (presumivelmente um que não causará imediatamente a mesma exceção!)
Além disso, em sistemas em que a entrada do usuário pode ser a causa / solução de um problema, as exceções podem permitir que o usuário saiba informações detalhadas e úteis sobre o problema. Em vez da muito comum "Ocorreu uma exceção não tratada em ..." ou "Intimidando mensagem de erro diretamente do SQL", você pode dizer ao usuário algo útil ou pelo menos compreensível, como "Não foi possível conectar ao recurso B."
Exceções foram criadas para simplificar o tratamento de erros. Sem exceções, a lógica de tratamento de erros deve ser espalhada por um aplicativo. Qualquer função que possa resultar em erro deve, de alguma forma, retornar um status de erro e cada chamada deve ser seguida de uma verificação de erro. Freqüentemente, o chamador não pode fazer nada útil em caso de erro e pode retornar apenas um erro. Metade do código do aplicativo pode ser dedicado ao tratamento de erros. Esse código é extremamente frágil. É muito fácil deixar de fora uma verificação de erro e travar, ou pior, retornar resultados incorretos devido a um erro despercebido.
Com exceções, os erros podem ser verificados apenas no ponto em que podem ser manipulados. A maioria dos códigos de aplicativos pode ser escrita de maneira linear, pois as funções retornam um valor utilizável ou lançam uma exceção.
O objetivo de uma exceção deve ser informar o usuário sobre circunstâncias excepcionais. Se algo der errado com o sistema, o programa deve saber e ter permissão para lidar com isso * adequadamente.
Dito isto, não, não existe uma exceção para impedir que o sistema "falhe". Uma exceção é me avisar que há um problema. A maneira como procedo determina pode determinar se o sistema "trava".
Observe também que uma exceção não precisa encerrar um aplicativo como você disse. Uma exceção pode ser tratada pelo programador e corrigida ou transformada em algum erro significativo para o usuário.
* O uso de exceções verificadas (exceções que são forçadas a serem capturadas) é um pouco dolorido. Alguns desenvolvedores (talvez a maioria) acham que o tratamento forçado de exceções é complicado, desnecessário e apenas uma prática ruim.
As exceções permitem o tratamento moderno de erros dividindo o local do erro do manipulador de erros. Às vezes, isso também é usado para controle de fluxo.
Exceções não tratadas encerram um programa. Mas elas não são diferentes das exceções anteriores, apenas um programador preguiçoso que esqueceu de incluir manipuladores de erros adequados em todos os caminhos os torna visíveis para o usuário final. Considero um programa encerrado por exceção como travado da mesma forma que qualquer outro fim inesperado.
Os sistemas operacionais são muito bons para limpar os processos com falha, independentemente de como eles foram travados; portanto, as exceções não adicionam segurança ao sistema operacional de outra maneira que não seja o encerramento de processos com defeito e a liberação de seus recursos.
É muito simples.
Antes que as exceções fossem inventadas, todas as funções precisavam retornar um código de saída (erro / sucesso) e qualquer resultado ou saída da função precisava ser recuperado, passando um ponteiro para a memória a ser definida por ela.
O problema era que muitos programadores não se lembravam / se preocupavam em procurar códigos de saída errôneos para cada função e, portanto, os erros fatais eram às vezes ignorados, levando a comportamentos inexplicáveis.
Portanto, foi decidido - quando ocorrer um erro, que você não levou em consideração, falhe imediatamente! Manipulação de exceção AKA.
Exceções são simplesmente um mecanismo de detecção de erros. Sozinhos, eles não têm utilidade.
Mas, ao detectar um erro, eles permitem acionar mecanismos de tolerância a falhas para se recuperar do estado incorreto, alternando para um estado livre de erros (um estado anterior ou um novo). Dessa forma, o erro não é propagado para outras partes do sistema.
Existem exceções para separar o fluxo normal do programa (o que o programa foi projetado para fazer) do fluxo de tratamento de erros (como o programa está tentando se recuperar de uma situação excepcional).
Isso torna o código mais claro e fácil de manter.
Considere dois trechos de código:
try:
do1() # this is obvoiusly a normal
do2() # program flow
except:
oups() # this is exception handling code
Comparado a este:
if foo():
thing1() # is this part of normal program flow?
else:
thing2() # or maybe this one? Or both? When?
Obviamente, o tratamento de exceções pode ser usado para impedir a falha do programa:
try { // very bad code
my();
whole();
ugly();
application();
here();
} catch (Throwable t) {
// pretend it's ok
}
mas esse não é o motivo das exceções nas linguagens de programação modernas.
Você também pode usar whilee break, em vez de if, mas não é isso que whilee breaksão para.