Administración de errores (parte 2)

Entre las cosas que no debemos hacer cuando administramos errores están:
C# .NET

try {
  Function1();
} catch {}
Function2();

ASP

on error resume next
…
Function1()
Function2()
…

En ambos casos se está enmascarando a los errores y no administrándolos. Si bien esto hará que el usuario no vea ningún error, el peligro es muy grande, tal como se describió en el artículo anterior.

Veamos otro ejemplo de lo que no debemos hacer:
C#.NET

public bool DeleteFile(string fileName) {
  bool canDelete=false;
  try {
    System.IO.File.Delete(fileName);
    canDelete=true;
} catch {}
  return canDelete;
}

ASP

Function DeleteFile(fileName)
  On error resume next
  Dim fso, canDelete
  Set fso = CreateObject("Scripting.FileSystemObject")
fso.DeleteFile(fileName)
  Set fso = Nothing
  canDelete = (Err.number=0)
  Err.Clear
  DeleteFile = canDelete
End Function

Esta es una muy mala práctica. Hemos creado una función que intenta borrar un archivo y devuelve el éxito de la operación. Además de las razones dadas en el ejemplo anterior, acá se agrega que quién llama a la función debe revisar si la función tuvo éxito revisando su valor de verdad. Pero en el caso de que la función devuelva falso, no tenemos ninguna otra información útil que nos sirva para tomar decisiones. No es lo mismo que la función haya fallado porque no tiene permisos a que el archivo no exista.

En el próximo artículo veremos algunas buenas prácticas en la administración de errores.