Não sei se existe ou não uma teoria, mas pode haver uma ciência experimental pragmática emergente.
A melhor fonte em que consigo pensar é Bjarne Stroustrup, The Design and Evolution of C ++, Addison-Wesley, 1994 . Se bem me lembro (é um livro muito bom e as pessoas continuam me emprestando e não o devolvendo, então não tenho uma cópia no momento), há um capítulo sobre exceções. O comitê C ++ no Stroustrup exigiu muitas evidências empíricas de que um recurso proposto era necessário antes que eles desejassem adicioná-lo à definição de linguagem. A página da Wikipedia sobre exceções tem a seguinte citação desse livro:
Na reunião de Palo Alto [padronização do C ++] em novembro de 1991, ouvimos um resumo brilhante dos argumentos para a semântica de terminação, apoiados tanto pela experiência pessoal quanto pelos dados de Jim Mitchell (da Sun, anteriormente da Xerox PARC). Jim utilizou o tratamento de exceções em meia dúzia de idiomas durante um período de 20 anos e foi um dos primeiros defensores da semântica da retomada como um dos principais designers e implementadores do sistema Cedar / Mesa da Xerox. Sua mensagem foi de encerramento é preferível à retomada; isso não é uma questão de opinião, mas uma questão de anos de experiência. O reinício é sedutor, mas não é válido. Ele apoiou essa declaração com experiência em vários sistemas operacionais. O exemplo principal foi Cedar / Mesa: foi escrito por pessoas que gostaram e usaram a retomada, mas após dez anos de uso, restava apenas um uso de retomada no sistema de meio milhão de linhas - e isso era uma investigação de contexto. Como a retomada não era realmente necessária para uma consulta de contexto, eles a removeram e encontraram um aumento significativo da velocidade nessa parte do sistema. Em todos os casos em que a retomada havia sido usada, ela se tornou um problema ao longo dos dez anos e um design mais apropriado a substituiu. Basicamente, todo uso de retomada representou uma falha em manter níveis separados de abstração separados. Em todos os casos em que a retomada havia sido usada, ela se tornou um problema ao longo dos dez anos e um design mais apropriado a substituiu. Basicamente, todo uso de retomada representou uma falha em manter níveis separados de abstração separados. Em todos os casos em que a retomada havia sido usada, ela se tornou um problema ao longo dos dez anos e um design mais apropriado a substituiu. Basicamente, todo uso de retomada representou uma falha em manter níveis separados de abstração separados.
No C ++, a vitória real é o RAII , o que facilita muito o tratamento da desalocação de recursos durante erros. (Não elimina a necessidade de throwe try- catch, mas significa que você não precisa finally.)
Acho que o que os convenceu de que precisavam de exceções são os contêineres genéricos: o gravador de contêineres não sabe nada sobre os tipos de erros que os objetos contidos podem precisar retornar (muito menos como lidar com eles), mas o código que inseriu esses objetos no diretório O container deve saber algo sobre o que é a interface desses objetos. Mas como não sabemos nada sobre que tipos de erros os objetos contidos podem gerar, não podemos padronizar os tipos de exceção. (Contrapositivamente: se pudéssemos padronizar os tipos de exceção, não precisaríamos de exceções.)
A outra coisa que as pessoas parecem ter aprendido ao longo dos anos é que é difícil colocar corretamente as especificações de exceção em um idioma. Veja, por exemplo, o seguinte: http://www.gotw.ca/publications/mill22.htm , ou isto: http://www.gotw.ca/gotw/082.htm . (E não é apenas C ++, os programadores Java também têm argumentos longos sobre suas experiências, com exceções verificadas versus não verificadas .)
Um pouco sobre a história das exceções. O artigo clássico é: John B. Goodenough: "Tratamento de exceções: questões e uma notação proposta", Commun. ACM 18 (12): 683-696, 1975. Mas exceções eram conhecidas antes disso. Mesa os possuía em 1974, e PL / I também os possuía. Ada tinha um mecanismo de exceção antes de 1980. Acredito que as exceções do C ++ foram mais influenciadas pela experiência com a linguagem de programação CLU de Barbara Liskov, de cerca de 1976. Barbara Liskov: "Uma história da CLU", em História das linguagens de programação --- II , Thomas J. Bergin, Jr. e Richard G. Gibson, Jr. (Eds.). 471-510, ACM, 1996 .