Programación defensiva y manejo de excepciones

Question

Hace un par de días, tengo las siguientes preguntas teóricas sobre el examen: (a) Explique qué se entiende por programación defensiva cuando se trata de circunstancias excepcionales que pueden ocurrir durante la ejecución de un programa . Puede consultar ejemplos vistos en clase o utilizar el código pseudo para describir los pasos que se han tomado para evitar que ciertas circunstancias se produzcan al intentar leer un archivo, por ejemplo. [5 puntos]

(b) Describa brevemente en términos generales lo que significa el manejo de excepciones en Java y cómo esto difiere de la programación defensiva. [5 puntos]

Siempre pensé que la programación defensiva es todo el paradigma de la programación y que el manejo de excepciones es la parte de la misma. Durante el examen escribo que en la "programación defensiva", el programador intenta descubrir todos los problemas posibles antes de ejecutar el código lógico y luego el valor de error de retorno (ejemplo 0) de esta función, mientras que en el manejo de excepciones ocurren atrapado por un mecanismo especial, en el que estos errores se interpretan directamente. ¿Es correcto? ¿Cuáles deberían ser las respuestas correctas?

Answer 1

Programación defensiva, para mí, significa escribir código para manejar casos que usted no cree que, o incluso, puede suceder, porque tiene la creencia de que sus propias creencias no son confiables.

Por ejemplo (no compilado o probado, términos y condiciones se aplican):

private String findSmallestString(Collection<String> strings) { 
    if (strings == null || strings.isEmpty()) return null; 
    Iterator<String> stringsIt = strings.iterator(); 
    try { 
     String smallestString = stringsIt.next(); 
     while (stringsIt.hasNext()) { 
      String candidateString = stringsIt.next(); 
      if (candidateString == null) continue; 
      if (candidateString.compareTo(smallestString) < 0) { 
       smallestString = candidateString; 
      } 
     } 
     return smallestString; 
    } 
    catch (NoSuchElementException e) { 
     return null; 
    } 
} 

En allí, características posiblemente defensivos incluyen:

• La cláusula de guardia null-o-vacío en la parte superior ; este es un método privado, por lo que debe estar en condiciones de garantizar que nunca se invoca con una colección nula o vacía
• El try-catch para NoSuchElementException; puede probar que el código que contiene nunca lanzará esta excepción si el iterador cumple con su contrato.
• La cláusula de nulidad en las cadenas (¡excepto la primera!) Que sale del iterador; de nuevo, ya que este es un método privado, probablemente debería ser capaz de asegurar que el parámetro de la colección no contiene valores nulos (y lo que estaría haciendo poner nulos en las colecciones de todos modos?)

No todo el mundo estaría de acuerdo en que la hipótesis nula los cheques son defensivos. El try-catch es, hasta el punto de ser completamente sin sentido.

Para mí, la prueba de fuego de la programación defensiva es que no creo que la defensa vaya a ser utilizada alguna vez.

Answer 2

Para mí, la programación defensiva está asumiendo el peor de los casos: que tus usuarios son completamente locos y debes defenderte a ti mismo y a tu programa de sus locos insumos. Creo que hay mucha sabiduría en esta cita:

Todos los días, la industria del software está haciendo un software más grande y mejor a prueba de tontos, y todos los días, la naturaleza está haciendo más grandes y mejores tontos. Hasta ahora la naturaleza está ganando

Y nunca olvide que sus usuarios no son solo sus clientes. Si eres responsable de una API de la biblioteca, tus usuarios podrían ser otro departamento.En ese caso, uno de los más estelar a reclamación que he oído en mi vida fue:

Incluso después de que hemos eliminado todas las pruebas unitarias fallidos, el programa no funcionó