Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 539 — #577
✐
62. Use las constantes con corrección. Esto permite que el compilador advierta de
errores que de otro modo serían sutiles y difíciles de encontrar. Esta práctica
requiere de cierta disciplina y se debe usar de modo consistente en todas sus
clases, pero merece la pena.
63. Use la comprobación de tipos del compilador en su beneficio. Haga todas las
compilaciones con todos los avisos habilitados y arregle el código para eliminar
todas las advertencias. Escriba código que utilice los errores y advertencias de
compilación (por ejemplo, no use listas de argumentos variables, que eliminar
todas los comprobaciones de tipos). Use assert() para depurar, pero use
excepciones para los errores de ejecución.
64. Son preferibles los errores de compilación que los de ejecución. Intente manejar
un error tan cerca del punto donde ocurre como sea posible. Es mejor tratar el
error en ese punto que elevar una excepción. Capture cualqueir excepción en el
manejador más cercano que tenga suficiente información para tratarla. Haga lo
que pueda con la excepción en el nivel actual; si no puede resolver el problema,
relance la excepción. (Vea el Volumen 2 si necesita más detalles.)
65. Si está usando las especificaciones de excepción (vea el Volumen 2 de este libro,
disponible en www.BruceEckel.com, para aprender sobre manejo de excepciones),
instale su propia función unexpected() usando set_unexpected().
Su unexpected() debería registrar el error y relanzar la excepción actual. De
ese modo, si una función existente es reemplazada y eleva excepciones, dispondrá
de un registro de FIXME:culprint y podrá modificar el código que la
invoca para manejar la excepción.
66. Cree un terminate() definida por el usuario (indicando un error del programador)
para registrar el error que causó la excepción, después libere los
recursos del sistema, y termine el programa.
67. Si un destructor llama a cualquier función, esas funciones podrían elevar excepciones.
Un destructor no puede elevar una excepción (eso podría ocasionar
una llamada a terminate(), lo que indica un error de programación), así
que cualquier destructor que llame a otras funciones debe capturar y tratar sus
propias excepciones.
68. No «decore» los nombres de sus atributos privados (poniendo guiones bajos,
notación húngara, etc.), a menos que tenga un montón de valores globales ya
existentes; en cualquier otro caso, deje que las clases y los espacios de nombres
definan el ámbito de los nombres por usted.
69. Ponga atención a la sobrecarga. Una función no debería ejecutar código condicionalmente
basandose en el valor de un argumento, sea por defecto o no. En
su lugar, debería crear dos o más métodos sobrecargados.
70. Oculte sus punteros dentro de clases contenedor. Dejelos fuera sólo cuando
vaya a realizar operaciones con ellos. Los punteros ha sido siempre la mayor
fuente de errores. Cuando use new, intente colocar el puntero resultante en un
contenedor. Es preferible que un contenedor «posea» sus punteros y sea responsable
de la limpieza. Incluso mejor, envuelva un puntero dentro de una
clase; si aún así quiere que parezca un puntero, sobrecargue operator-> y
operator*. Si necesita tener un puntero normal, inicialicelo siempre, preferiblemente
con la dirección de un objeto, o cero si es necesario. Asignele un cero
cuando le libere para evitar liberaciones múltiples.
539
✐
✐
✐
✐