Android : comment traiter les exceptions d'accès à la base de données ?

Question

Ma question porte sur les bonnes pratiques en matière de traitement des exceptions dans la base de données.

Disons que j'ai une application qui stocke des données dans une base de données. Les couches suivantes sont implémentées :

1. DatabaseAdapter - traite les requêtes SQL et fournit des données à la couche supérieure sous la forme d'un modèle. L'adaptateur contient des méthodes comme :
   • Liste getAllUsers()
   • void addUser(UserModel utilisateur)
2. UserListActivity - affiche la liste de tous les utilisateurs, permet d'ajouter un nouvel utilisateur, etc. Cette activité utilise DatabaseAdapter pour lire/écrire la base de données.

La question est la suivante : dois-je gérer une exception d'accès à la base de données, par exemple lors de l'ajout d'un nouvel enregistrement (en supposant que l'enregistrement doit toujours être ajouté correctement) ? Dois-je simplement essayer d'attraper l'exception dans DatabaseAdapter et l'ajouter au journal ? Ou peut-être ne devrais-je pas l'attraper du tout ?

Answer 1

La plupart du temps, une exception lors de l'interrogation d'une base de données est le résultat d'une erreur de "développement", comme une requête malformée, ou la modification de votre schéma sans incrémenter la version de la base de données, ou quelque chose de ce genre. Ces erreurs sont faciles à trouver et à corriger sur le champ, de sorte que vos utilisateurs finaux ne sont pas affectés par ce type d'erreurs.

Toutefois, il existe également de réelles possibilités d'exceptions dans les cas suivants :

• Vous essayez d'accéder à votre base de données SQLite à partir de plusieurs processus (une recette pour un désastre).
• L'utilisateur manque d'espace disque sur son appareil.
• Vous avez une requête malformée parce que l'entrée de l'utilisateur n'a pas été escapée correctement.
• Il y a un bug dans votre onUpgrade() ou quelque chose comme ça.
• Vous utilisez l'intégrité référentielle (possible dans SQLite 3.6.19 et plus) et une contrainte de table échoue.

Il n'y a pas de réponse universelle pour ces scénarios. Pour l'utilisateur final, l'affichage d'une simple erreur est beaucoup plus agréable que la fermeture forcée de votre application, par exemple.

Ma règle d'or est d'éviter à tout prix la corruption de votre base de données. Je préfère de loin lancer un RuntimeException et tuer immédiatement l'application plutôt que de la laisser faire quelque chose de mal en silence. De même, je préférerais afficher un message indiquant qu'une insertion n'a pas pu être effectuée plutôt que de forcer la fermeture de l'application.

Answer 2

Il n'y a pas de réponse commune à cette question qui convienne toujours. Deux règles s'appliquent cependant toujours : ne pas transmettre de messages d'exception trop détaillés à la couche supérieure (l'interface utilisateur n'a pas besoin de connaître un problème de syntaxe SQL) et traiter l'exception là où cela a du sens (ne pas afficher de boîte de dialogue d'erreur dans votre classe DB). Vous pourriez par exemple attraper l'exception de base de données dans la classe de base de données, l'enregistrer et ensuite relancer une exception personnalisée CustomerNotFoundException qui est attrapée dans l'interface utilisateur où vous pouvez afficher un dialogue d'erreur.