c# - tipos - ¿Debería mi método lanzar su propia excepción, o dejar que.NET lance si no existe un archivo?

tipos de excepciones programacion

Question

Aquí está mi código:

public void ReadSomeFile(string filePath)
{
    if (!File.Exists(filePath))
        throw new FileNotFoundException();

    var stream = new FileStream(filePath, ....)
    .....
}

¿Debo lanzar una excepción yo mismo (ver la verificación File.Exists )? FileStream ya lanzará FileNotFoundException si el archivo no existe. ¿Qué es una buena práctica de programación aquí? El análisis de código dice que debemos validar nuestros parámetros. Pero si paso ese parámetro directamente a otro método (el mío o el código de otra persona) y ese método arrojará una excepción, entonces ¿cuál es la ventaja de validar el argumento en mi código?

Answer 1

Además de las respuestas ya dadas, también podría decir que esto depende de lo que espera que suceda.

Si desea leer un archivo de registro y no existe, ¿desea lanzar un error, o simplemente una cadena vacía (o una matriz de cadenas vacía)?

Si devuelve un valor predeterminado (como una Cadena vacía), simplemente envolvería el contenido de la función en un try-catch (pero solo para los errores esperados) y devolvería el valor predeterminado en el bloque catch , mientras devolvía el contenido real en el bloque try .

Esto dejaría tres situaciones posibles:

1. Se devuelve el contenido de un archivo;
2. Se devuelve el valor predeterminado porque se produjo un error esperado;
3. .NET genera un error porque no captó ese error específico.

Answer 2

Deje que el método correcto intente abrir el archivo mientras no tenga idea del nombre completo del archivo, algunas cosas como nombres de archivo especiales (por ejemplo, archivos de dispositivo y rutas UNC ):

En algunos casos, otros métodos de archivo pueden fallar, pero la apertura del archivo es exitosa.

Algunos ejemplos de nombres de archivos especiales son:

• ESTAFA
• NUL
• COM1, COM2, COM3, COM4
• // server / share / file_path
• // teela / admin $ / system32 (para llegar a C: / WINNT / system32)
• C: .. / File.txt
• //. / COM1
• %TEMPERATURA%
• y más...

Answer 3

Su método se llama ReadSomeFile y toma un filename como entrada, por lo tanto, es razonable que arroje una FileNotFoundException . Como no puede agregar ningún valor al capturar la excepción y luego lanzarla usted mismo, simplemente deje que .NET la arroje.

Sin embargo, si su método fue LoadData(databaseName) y tiene que acceder a muchos archivos, detectar la excepción y lanzar una excepción personalizada puede ser de valor, ya que podría agregar databaseName a la excepción junto con otra información útil.

Answer 4

if (File.Exists(f)) { DoSomething(f) } (o la negación del mismo) es un antipatrón. El archivo se puede eliminar o crear entre esas dos declaraciones, por lo que tiene poco sentido verificar su existencia de esa manera.

Aparte de eso, como se señaló en los comentarios, aunque File.Exists() puede volver verdadero, la apertura real del archivo aún puede fallar por una variedad de razones. Por lo tanto, tendrá que repetir la comprobación de errores y lanzar alrededor de la apertura del archivo.

Como no desea repetirlo, sino que mantenga su código SECO, solo intente abrir el archivo y deje que se inicie new FileStream() . Luego puede atrapar la excepción y, si lo desea, volver a lanzar el original o lanzar una excepción específica de la aplicación.

Por supuesto, llamar a File.Exists() puede justificarse, pero no en este patrón.