No hay respuestas en este tema

[cram]

Evitar o resolver, ceñir o ampliar. Quizá ambos según el caso.

Cualquier error o inconveniente que resulte en una excepción o termine dando un resultado erróneo en la aplicación debe ser evitado o resuelto de alguna manera.
El tema es si conviene evitar que esto ocurra o resolverlo despues que ocurra.

A. El uso de Try
Se supone que utilizar Try hace que el código crezca considerablemente, además de agregarse los que se podría llamar como una capa extra al código del ejecutable.
Por otra parte, la mayoría de los casos de error, sino todos, es posible evitarlos, a excepción de aquellos errores ocasionados por condiciones externas. Supongo que por esta razón fue creado el mecanismo detrás de la sentencia Try...
Delphi puede implementar dos formas de Try:
1) Try Finally, y
2) Try Except

En el primer caso, es posible dejar las cosas en buen estado más allá de haber ocurrido un error o no. Se utiliza en el caso de abrir un archivo, crear un objeto en memoria, u otro similar. La idea es que cuando ocurra un error sea posible cerrar el archivo abierto o destruir el objeto liberando la memoria utilizada por el mismo o algún otro caso de restaración de un entorno anterior a la llamada de las sentencias protegidas.

// Crea una clase de tipo TComponent y realiza alguna operación con ella
UnaClase := TComponent.Create(Self);
try
  // Operaciones protegidas para la clase UnaClase
finally
// Aun cuando OtraClase no esté asignada y genere un error al momento de asignarla
// el objeto UnaClase se puede liberar;
  UnaClase.Free;
end;

En el segundo caso, es posible controlar sin problemas mayores la ocurrencia de un error. Por ejemplo, la división por cero, intentar abrir un archivo que no existe, una conversión errónea, etc. En este caso es posible capturar la excepción y emitir un mensaje o actuar de otra manera para corregir el problema.

// Asigna el valor cero a la variable A en caso de ser C igual a 0;
Try
  A:= B/C;
Except
  On EDivByZero do A:= 0;
End;

El tema de los códigos protegidos es que realmente dotan de seguridad a los programas durante su ejecución sin importar el costo que esto implique.
En muchos ejemplos de la ayuda OnLine de Delphi se puede ver como evitar muchas de las excepciones y así evitar también el uso de Try.
Así el caso de la división por cero podría cambiarse por:

if C <> 0 then A:= B/C; // Evita la división por cero.

No solo evita el problema, sino que ayuda mucho a la lectura del código.

Go, un lenguaje creado recientemente (por Google) no utiliza Try. Porque ellos creen que agrega complejidad innecesaria al compilador.
que éste cometa los errores.

B. Control de lo que el programa "digiere"
En el caso de la entrada de datos, también ocurre que es posible crear mecanismos correctivos luego de ingresar datos o evitar que se ingresen datos incorrectos o inapropiados para el uso que se le piensa dar.
Conozco programadores que permiten la incorporación de cualquier caracter en un cuadro de edición (TEditBox) y luego implementan una acción correctiva. Esto, sumado a esto, agregan mensajes que congelan la ventana y dicen algo como "No se permite *'. La otra opción es impedir el uso de estos caracteres, evitando así dos cosas: el error y el aviso.
Es evidente la diferencia entre una metodología y otra. Pero dado que un programa puede ser utilizado por cualquier tipo de usuarios, este tema agrega dificultad al tratamiento de los datos ingresados.

C. Ceñimiento de las posibilidades
Por otra parte, el uso de menús descolgables, cantidad enorme de botones, etc. Cada uno con su tecla rápida que el operador podrá recordar a medida que utilice el programa (al menos las más usadas) y por otra parte el uso de una interfz minimalista con la mayoría de la funcionalidad puesta en pocos controles y uso de la lógica para restringir posibilidades o deducir sus posibles usos, haciendo de la interfaz sensible al contexto.
Esta técnica de programación no se si llamarla a la defensiva o adelantada, la vengo aplicando desde hace mucho. Recuerdo que en mis años de estudiantes, se utilizaba mucho el uso de los botones o elementos del menú para alta, baja y modificación de un elemento (fila, instancia de entidad), luego de esto se solicitaban los datos. Aquí es donde ocurría una serie de cosas, como por ejemplo que la instancia a eliminar o modificar no existía, o aquella a crear ya existía, etc. Mi forma de hacerlo en aquel entonces invertía el asunto, pidiendo antes una clave que identifique unívocamente al elemento, si existía sería posible eliminarlo o modificarlo, si no, sería posible crearlo.
Recientemente, hace aproximadamente un año, un amigo de esos que andan por mal camino (es programador de C Sharp y MS-SQL) afirmó haberme copiado esa metodología, claro que no es mi metodología, supongo que existen muchos que la aplican y obviamente existirán programadores que la usan mejor incluso.
En este camino, existen muchas otras soluciones y actualmente con el uso de pantallas de tamaño reducido son cada vez más usadas.

D. Visibilidad y Habilitación
Este tema está muy ligado a los dos anteriores y se trata de la visibilidad de controles o su habilitación solo cuando son necesarios o útiles.
Es el caso de esas interfaces abarrotadas como la de Office 97, en la que se puede agregar botones rápidos hasta que realmente no quede espacio para escribir. Y por otro lado el uso de la cinta de opciones (ribbon) que es sensible al contexto agrupa a los controles afines en un solo lugar con el fin de evitar búsquedas de botones por parte del usuario.
Otro es el caso de aquellos formularios web que solicitan datos y tienen un botón que dice enviar (o send) y luego de -para colmo- vaciar los controles ya ingresados marcar aquellos que hacían falta y no llenamos. También existen otros formularios web que no nos muestran el botón (o lo deshabilitan) hasta que no se hayan llenado los campos necesarios para el envío.
En la mayoría de las aplicaciones que escribo intento aplicar la regla de no permitir al usuario terminar un proceso cuando éste no está acabado (no tiene todos los datos necesarios), creo que esto puede evitar dos cosas: por parte del usuario, frustración y por parte del programador, evitar tener que agregar mensajes para los errores.
Resumiendo, mientras que el entorno no está preparado mantener deshabilitado el botón [OK], pero dejar el botón [Cancel].

E. Deducción
Creo que entre todos es el más fino y elegante, fino porque requiere mucha precisión en su implementación y elegante, porque reúne muchas características avanzadas de implementación que lo hacen realmente interesantes tanto en su uso como en su codificación, además de de ser eficiente.
Un caso muy simple es la entrada de datos de diferente uso pero igual naturaleza en un mismo control, el programa es el que se encargará de saber que hacer con él.
La otra cara de la moneda, como lo hacemos siempre (o casi), un control para cada uso y su etiqueta arriba o a la izquierda.
Un caso de éxito: el omnibox de Chrome.
El abuso de esta técnica puede ser contraproducente (muy al este es el oeste).

Y es todo, quizá me falten algunas o sobren otra, pero tampoco quiero escribir un libro.

Este tema es para el debate y así compartir nuestros puntos de vistas y soluciones más usadas.

Saludos