Gestion des erreurs par défaut avec RxJava
Jetez un œil au flux de vote ci-dessous:
Chaque seconde, nous rafraîchissons notre vue. Remarquez que je n’ai pas géré l’erreur. Eh bien, qu’est-ce qui pourrait mal tourner? Ce n’est pas comme si le interval la méthode de RxJava échouera!
Extrayons maintenant le mécanisme d’interrogation dans une autre classe. Je l’ai appelé PollableViewModel. PollableView ne doit pas savoir comment le modèle de vue gère l’interrogation. Seul son contrat: il scrute chaque seconde.
Pour une raison stupide, le startPolling en amont fonctionne sur le résultat d’intervalle. En essayant de le diviser par zéro, le flux délivre un ArithmeticException.
En aval, le flux générera une erreur lorsque PollableView appellera poll(). Étant donné que nous n’avons pas mis en œuvre le onError rappel, nous obtenons l’infâme OnErrorNotImplementedException.
Dans ce cas d’utilisation, j’ai forcé une exception en utilisant du code stupide. Cependant, une exception pourrait être levée pour une raison hors de votre portée.
Vous pouvez toujours décider de mettre en œuvre le onError rappeler.
Ici, nous enregistrons l’exception avec Charpente. Nous gérons en quelque sorte l’exception en la redirigeant vers la console de journalisation.
Je vois deux inconvénients importants:
- Il est fastidieux d’implémenter un rappel sans effectuer de véritable gestion des erreurs. Vous pouvez enregistrer l’erreur ou laisser le bloc vide. Cela ne vous apporte rien de lié à cette erreur spécifique.
- Vous n’avez aucun mécanisme pour vous assurer d’avoir traité tous vos rappels. Ce qui signifie qu’il pourrait encore planter quelque part. Et avouons-le, vous en oublierez certains. Pour répondre à ce problème, vous pouvez tirer parti des règles sur les peluches telles que RxLint. Mais encore une fois, ne pas faire de gestion des erreurs.
Ou vous pouvez décider d’utiliser le RxJavaPlugins gestionnaire d’erreurs. Il recevra toutes les exceptions partout onError les implémentations sont manquantes. Vous pouvez indiquer ce qu’il faut effectuer lorsque de tels cas se produisent.
Ajoutez ce code dans votre onCreate Douane Application classe:
RxJavaPlugins.setErrorHandler(Timber::e)
Nous pouvons décider comme ci-dessus de consigner toutes les exceptions non capturées. Vous pouvez supprimer toutes les implémentations onError qui ne gèrent pas non plus les erreurs. le RxJavaPlugins le gestionnaire d’erreurs vous a couvert. Pas plus OnErrorNotImplementedException crash!
En utilisant la gestion des erreurs par défaut, certains peuvent signaler la perte de certaines informations de la trace de pile.
Étant donné que la trace de la pile RxJava ne se distingue pas de toute façon par sa clarté, je recommande de combiner le gestionnaire d’erreurs par défaut avec RxDogTag. Vous obtiendrez des journaux ciblant le flux défectueux. Une grande aide lors du débogage!
RxDogTag.install()
RxJavaPlugins.setErrorHandler(Timber::e)
L’ajout d’une gestion des erreurs par défaut peut sembler sujet aux erreurs. Vous auriez raison de dire que nous cachons des problèmes potentiels.
Mais les erreurs de journalisation partout ne vous rendront pas justice non plus – mieux lutter contre les erreurs là où cela est important et se replier dans la journalisation. Vous ne verrez pas votre application se bloquer. Sans parler de la joie de ne pas ajouter d’implémentations de rappel par défaut à chaque flux.
Dans cet exemple, j’ai illustré une gestion des erreurs de base. La journalisation ne sera pas suffisamment proche pour empêcher votre code de comportements corrompus. Dans mon entreprise, nous avons ajouté une autre couche de journalisation qui enverrait des rapports en tant que plantages non fatals sur Firebase. Cette couche filtre les types d’exception en fonction de ce qui est pertinent à consigner.
le RxJavaPlugins le gestionnaire d’erreurs est suffisamment flexible pour vous permettre d’effectuer ce qui vous convient le mieux. J’espère que cela vous fera gagner du temps et éviter des plantages évitables.
