java - puede - saber si existe un archivo c#
Compruebe si existe un archivo antes de llamar a openFileInput (3)
Para leer un archivo en Android desde el área de almacenamiento privado de su aplicación, use la función openFileInput() .
Mi pregunta es, ¿hay alguna forma de verificar si este archivo existe antes de llamar a esta función? La función puede lanzar una FileNotFoundException , pero tengo ganas de llamar esto y luego hacer algo basado en un try - catch es una mala práctica.
Usar File.exist() parece algo extraño de usar, ya que requeriría la creación de una clase y no estoy seguro de que al pasarle el nombre del archivo se encuentre el archivo en el área privada de mi teléfono. .
La función puede a través de una excepción FileNotFoundException, pero siento que llamar esto y luego hacer algo basado en una captura de prueba es una mala práctica.
Estoy en desacuerdo. En mi opinión, está comprobando si el archivo existe antes de abrirlo, es una mala práctica. Compara estas dos versiones del código:
File f = new File("someFile");
InputStream is;
Versión 1
if (f.exists()) {
is = new FileInputStream(f);
...
} else {
System.err.println("Doesn''t exist");
}
Versión 2
try {
is = new FileInputStream(f);
...
} catch (FileNotFoundException ex) {
System.err.println("Doesn''t exist");
}
Hay una serie de problemas con la primera versión:
La versión # 1 hace una llamada adicional al sistema cuando llama a
f.exists(). Esto hace que la primera versión sea más lenta en promedio, a menos que haya una alta probabilidad de que el archivo no exista.La versión # 1 tiene una condición de carrera. Si algún proceso externo elimina el archivo aproximadamente al mismo tiempo, podría terminar con
file.exists()devuelve true, y luego el constructorFileInputStreamlaFileInputStreamFileNotFoundException. Este es el tipo de condición de carrera que se puede aprovechar para romper la seguridad si el archivo en cuestión es crítico para la seguridad. (En realidad, también hay una segunda condición de carrera, donde se crea el archivo yfile.exists()devuelve false cuando un intento posterior de abrirlo tendría éxito. Pero esa condición de carrera es probablemente inofensiva).
Otro problema es que FileInputStream se declara como lanzando IOException . Las pruebas para ver si el archivo existe solo tratan con uno de los posibles modos de falla. Su código tendrá que capturar y lidiar con esas otras IOException s de todos modos.
@Pieces comentó:
Las excepciones deben ser cuando algo realmente falla sobre lo que no tienes control. En este caso, tengo el control total sobre él.
En realidad, no tienes control completo sobre él. Ciertamente no en el caso general. Incluso en su caso de uso particular, la condición de carrera todavía es posible en teoría.
Pero el problema real con esta línea de pensamiento es que terminas saltando a través de aros para evitar excepciones en situaciones donde las excepciones / manejo de excepciones son la mejor solución. Esto hace que el código sea más complicado, menos legible y potencialmente más lento y / o más frágil.
El dogma normal es así:
"Las excepciones solo deben usarse en situaciones excepcionales" .
Esto no es lo mismo que decir lo que dijiste. La palabra "excepcional" realmente significa "no normal". Esto tiene un significado mucho más amplio que "algo realmente sale mal sobre el que no tienes control".
Tiendo a expandir el dogma de la siguiente manera:
No se deben usar excepciones para el control de flujo normal.
No deben usarse excepciones si van a resultar demasiado caras en promedio .
Deben usarse excepciones si las pruebas que usaría para evitarlas no son confiables.
Se deben usar excepciones si las pruebas que usaría para evitarlas son, en promedio, demasiado caras.
Se deben usar excepciones si simplifican significativamente su código (módulo anterior). Y el criterio para la simplicidad es si un programador Java promedio puede leer el código.
(Nota - "en promedio" y " demasiado caro" ...)
Ahora se puede discutir hasta que las vacas vuelvan a casa sobre lo excepcional que debe ser un evento, pero mi opinión es que esto es realmente una cuestión de equilibrar la relativa simplicidad de los enfoques (en el contexto) versus los costos promedio de desempeño (en el contexto) ). Cualquier regla dogmática que no tenga en cuenta las concesiones y el contexto le hará daño en algunos casos.
Este trabajo para mí.
try {
FileInputStream fis = openFileInput(String filename);
// ... do something
try {
fis.close();
} catch (IOException e) {
e.printStackTrace();
}
}
} catch (FileNotFoundException e) {
e.printStackTrace();
}
pero sucede, algunas veces, devuelve una excepción igual ... trabajando con adb.
public boolean fileExists(Context context, String filename) {
File file = context.getFileStreamPath(filename);
if(file == null || !file.exists()) {
return false;
}
return true;
}
EDITAR:
Además, aquí hay otra forma de archivos en almacenamiento externo.
String fileUrl = "/appname/data.xml";
String file = android.os.Environment.getExternalStorageDirectory().getPath() + fileUrl;
File f = new File(file);
if(f.exists())
return;