No sé si existe o no una teoría, pero puede haber una ciencia experimental pragmática emergente.
La mejor fuente que se me ocurre es Bjarne Stroustrup, The Design and Evolution of C ++, Addison-Wesley, 1994 . Si recuerdo correctamente (es un libro muy bueno y la gente me lo sigue pidiendo prestado y no me lo devuelve, por lo que no tengo una copia en este momento) hay un capítulo sobre excepciones. El comité C ++ bajo Stroustrup requirió mucha evidencia empírica de que una característica propuesta era necesaria antes de que estuvieran dispuestos a agregarla a la definición del lenguaje. La página de Wikipedia sobre excepciones tiene la siguiente cita de ese libro:
En la reunión de Palo Alto [estandarización de C ++] en noviembre de 1991, escuchamos un resumen brillante de los argumentos para la semántica de terminación respaldados con experiencia personal y datos de Jim Mitchell (de Sun, anteriormente de Xerox PARC). Jim había utilizado el manejo de excepciones en media docena de idiomas durante un período de 20 años y fue uno de los primeros defensores de la semántica de reanudación como uno de los principales diseñadores e implementadores del sistema Cedar / Mesa de Xerox. Su mensaje de terminación es preferible a la reanudación; Esto no es una cuestión de opinión, sino una cuestión de años de experiencia. La reanudación es seductora, pero no válida. Respaldó esta declaración con experiencia de varios sistemas operativos. El ejemplo clave fue Cedar / Mesa: fue escrito por personas a las que les gustó y usaron la reanudación, pero después de diez años de uso, solo quedaba un uso de la reanudación en el sistema de medio millón de líneas, y esa fue una investigación de contexto. Debido a que la reanudación no era realmente necesaria para dicha investigación de contexto, la eliminaron y encontraron un aumento significativo de la velocidad en esa parte del sistema. En todos y cada uno de los casos en que se había utilizado la reanudación, durante los diez años se había convertido en un problema y un diseño más apropiado lo había reemplazado. Básicamente, cada uso de la reanudación había representado una falla en mantener separados los niveles de abstracción. En todos y cada uno de los casos en que se había utilizado la reanudación, durante los diez años se había convertido en un problema y un diseño más apropiado lo había reemplazado. Básicamente, cada uso de la reanudación había representado una falla en mantener separados los niveles de abstracción. En todos y cada uno de los casos en que se había utilizado la reanudación, durante los diez años se había convertido en un problema y un diseño más apropiado lo había reemplazado. Básicamente, cada uso de la reanudación había representado una falla en mantener separados los niveles de abstracción.
En C ++, la verdadera victoria es RAII , lo que hace que sea mucho más fácil manejar la desasignación de recursos durante los errores. (No acabar con la necesidad de throwe try- catch, sino que significa que no es necesario finally.)
Creo que lo que los convenció de que necesitaban excepciones son los contenedores genéricos: el escritor del contenedor no sabe nada sobre los tipos de errores que los objetos contenidos podrían necesitar devolver (mucho menos cómo manejarlos), pero el código que insertó esos objetos en el El contenedor debe saber algo sobre la interfaz de esos objetos. Pero como no sabemos nada acerca de qué tipo de errores pueden arrojar los objetos contenidos, no podemos estandarizar los tipos de excepción. (Contradictoriamente: si pudiéramos estandarizar los tipos de excepción, entonces no necesitaríamos excepciones).
La otra cosa que la gente parece haber aprendido a lo largo de los años es que las especificaciones de excepción son difíciles de poner correctamente en un idioma. Vea, por ejemplo, esto: http://www.gotw.ca/publications/mill22.htm , o esto: http://www.gotw.ca/gotw/082.htm . (Y no se trata solo de C ++, los programadores de Java también tienen largos argumentos sobre sus experiencias con excepciones marcadas frente a no marcadas ).
Un poco sobre la historia de las excepciones. El artículo clásico es: John B. Goodenough: "Manejo de excepciones: problemas y una notación propuesta", Commun. ACM 18 (12): 683-696, 1975. Pero antes se conocían excepciones. Mesa los tenía aproximadamente en 1974, y PL / I puede haberlos tenido también. Ada tenía un mecanismo de excepción antes de 1980. Creo que las excepciones de C ++ fueron más influenciadas por la experiencia con el lenguaje de programación CLU de Barbara Liskov de alrededor de 1976. Barbara Liskov: "Una historia de CLU", en Historia de los lenguajes de programación --- II , Thomas J. Bergin, Jr. y Richard G. Gibson, Jr. (Eds.). pp. 471-510, ACM, 1996 .