2011-01-01 14 views
6

Soy nuevo en el entorno de Android y he comenzado a escribir algunos códigos para ejecutar algunas consultas en una base de datos. Cuando tengo que manejar excepciones, no sé cuál es la forma adecuada de hacerlo: de Android solía usar la declaración throws sobre métodos, pero parece que throws no está permitido en Android? ¿Solo try-catch? Digo esto porque eclipse no sugiere que agregue throws declaración como cuando estoy fuera del entorno de Android, supongo que está relacionado con extends Activity. Entonces, ¿cuál es la forma apropiada de manejar excepciones en android? Rodeando cada oración con try-catch mi código se ve terrible y eso no es realmente lo que quiero hacer.Evita try/catch en Android

+0

¿Está hablando de anular/implementar métodos? Y ese "código terrible" solo significa que estás preparado para todas las situaciones posibles. Ah, por cierto: para 'RuntimeException' y sus subclases, no necesita" throws ". – thejh

+8

Android usa lenguaje Java, por lo que el manejo de excepciones es EL MISMO que en cualquier otro proyecto de Java. También es difícil adivinar su caso, por lo que probablemente podría ser más específico en su pregunta, p. podría dar una muestra de código para resaltar su problema. Creo que puede explicarse adecuadamente para usted entonces. –

+0

Lo que dijo Arhimed. Ver http://download.oracle.com/javase/tutorial/essential/exceptions/index.html – MatrixFrog

Respuesta

2

La razón por la que no puedes "agregar los lanzamientos en Android a través de eclipse" es porque no eres la persona que define las interfaces o las súper clases. Si desea agregar una excepción a la firma del método (como usted dice que hace normalmente), también debe agregarse a la interfaz y usted no puede controlarla, por lo que no puede modificarla.

ejemplo, el método

protected void onCreate (Bundle savedInstanceState);

la que se anula la actividad, si desea lanzar una excepción tendría que ser cambiado a la firma del método (por ejemplo)

protected void onCreate (Bundle savedInstanceState) lanza MiExcepción;

pero también debería cambiar dónde se define onCreate, que está en la clase Activity, y esa es una clase que no puede cambiar (porque la proporciona la biblioteca android).

Por lo tanto, su única opción es atrapar la excepción y hacer algo con ella (o simplemente ignorarla). Se podría hacer un brindis para mostrar el errror

catch (Exception e) { 
    Toast toast = Toast.makeText(this, e.getMessage(), Toast.LENGTH_SHORT); 
    toast.show(); 
} 
13

Si el método que está utilizando ya se produce una excepción, es posible que desee simplemente volver a producir la excepción, ya que el nuevo tipo:

public void someMethod() throws IOException { 
    try { 
     // Do database operation 
    } catch (MyException e){ 
     throw new IOException(e.toString()); 
    } 
} 

// Or, if there is no exception, use an unchecked exception: 

public void otherMethod() { 
    try { 
     // DB operation 
    } catch (MyException e){ 
     throw new RuntimeException(e); 
    } 
} 

El Otra opción es hacer que MyException extienda RuntimeException. Entonces el compilador no lo forzará a atraparlo o agregarlo a la firma del método. Las excepciones RuntimeExceptions se conocen como excepciones sin marcar, lo que significa que no tiene que comprobar que se produzcan mediante try/catch. Ejemplos de estos son NullPointer y ArrayOutOfBounds.

4

Me preguntaba sobre algún extraño manejo de "throws" en el entorno de Android y encontré esta vieja pregunta aquí. Asker Jon "comenzó a escribir código para ejecutar algunas consultas en una base de datos", por lo que tal vez notó lo mismo que yo.

Esto compila sin error:

public void onCreate(SQLiteDatabase db) 
{ 
    db.execSQL(DbMeta.T_DISGUISED.T_CREATE); 
} 

pesar de esta declaración (en el emergente javadoc):

void android.database.sqlite.SQLiteDatabase.execSQL(String sql) throws SQLException 

Así que, primero, monkjack es correcto cuando señala que la firma onCreate del método no puede ser cambiado al heredar implementaciones. Y segundo, Zeki indica correctamente la diferencia entre las excepciones marcadas y no marcadas.

Y ahora tercero, quiero agregar que la gran confusión es causada por SQLException.

La SQLException utilizada en el ejemplo anterior es Android tipo android.database.SQLException y hereda java.lang.RuntimeException - ¡es una excepción no comprobada! No se requiere declaración de tiro !!!

Ese no es el clásico java.sql.SQLException - que es un java.lang.Exception y requiere try/catch/throws.

Cuestiones relacionadas