¿Por qué android.database.SQLException está desmarcada?

Esto podría ser inadecuado para SO, ya que no es realmente un problema de codificación, pero no pude encontrar una respuesta satisfactoria todavía y creo que la comunidad SO puede.

Por lo tanto, por definición android.database.SQLException y java.sql.SQLException compartir sobre el mismo ámbito de aplicación, que es proporcionar información sobre los errores al acceder / modificar una base de datos. Aunque he leído en alguna parte que las excepciones comprobadas están "hacia fuera", realmente tengo gusto del hecho que el compilador le recuerda de manejar excepciones cuando usted utiliza excepciones comprobadas con la palabra clave throws . Desafortunadamente esto no funciona con excepciones no comprobadas.

Mi pregunta es: ¿Por qué Google hizo que su android.database.SQLException no esté marcada cuando java.sql.SQLException está marcada? ¿Me estoy perdiendo de algo? ¿Difieren más de lo que pienso?

    4 Solutions collect form web for “¿Por qué android.database.SQLException está desmarcada?”

    La elección entre hacer una excepción marcada o desmarcada siempre es algo subjetiva:

    • Si una excepción indica un error o algún fallo que es "probablemente no recuperable", entonces una excepción no comprobada es apropiada.

    • Si una excepción indica un error que es "probablemente recuperable", entonces una excepción seleccionada es apropiada.

    Es más difícil en casos como este donde hay una excepción general con muchas subclases. Algunas de esas subclases podrían ser bugs, o podrían ser recuperables. En este punto, el diseñador tiene que hacer un juicio de valor sobre la probabilidad relativa de los diferentes casos … a través de todos los subtipos conocidos / previstos de la excepción.

    En este caso, los ingenieros de Sun y Google llegaron a conclusiones diferentes. Pero tenga en cuenta que los ingenieros de Google tenían una gran ventaja que los ingenieros de Sun no tenían. Podían mirar el diseño de Java, y hacer su propio juicio sobre lo bien que funcionaba con una SQLException comprobada.


    Aunque he leído en alguna parte que las excepciones comprobadas son "out" …

    Hay un montón de desarrolladores que desean que todas las excepciones de Java fueron desmarcadas para que no tienen que ser obligados a tratar con ellos. Hay un montón de otros desarrolladores que todavía piensan que Java lo hizo bien con las excepciones comprobadas … a pesar de que hubo algunos casos donde se hizo la elección equivocada (en retrospectiva).

    Es discutible.

    ¿Me estoy perdiendo de algo? ¿Difieren más de lo que pienso?

    Realmente no. Las dos jerarquías de excepción sirven prácticamente el mismo propósito … las diferencias en las descripciones de las clases javadoc no obstante.

    android.database.SQLException se basa en java.lang.RuntimeException y no es necesario comprobarlo, pero java.sql.SQLException no lo es.

    En Unchecked Exceptions – The Controversy hay una explicación sencilla sobre esto.

    Creo que las excepciones no verificadas son preferibles a excepciones verificadas en muchos casos. La razón es que no estás obligado a atraparlo de ninguna manera. Puedes rodear tu código con una cláusula try-catch si crees que es necesario, pero no tienes que hacerlo. Esto efectivamente hace que su código mejor, como el programador puede decidir qué hacer.

    En su ejemplo, no hay una razón en particular por la que uno tiene que hacerlo o no. Es una cuestión de diseño, por lo que creo que Google hizo un mejor trabajo con android.database.SQLException .

    La razón por la que creo que es así es porque:

    Android.database.SQLException: Una excepción que indica que hubo un error con el análisis o la ejecución de SQL.

    y

    Java.sql.SQLException: Una excepción que proporciona información sobre un error de acceso a la base de datos u otros errores.

    Por lo tanto, está claro que android.database.SQLException es probable que RuntimeException porque se produce cuando hay un error con SQL de análisis o ejecución. Considerando que, java.sql.SQLException es una excepción causada debido al error de acceso a la base de datos u otros errores de este tipo, por lo que es lo suficientemente válido como para mantenerlo como una excepción controlada. Siempre que trabaje con conexiones abiertas, o cualquier otra cosa de ese tipo, es mejor tenerlas bajo el paraguas de la excepción verificada.

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.