Approche fonctionnelle de la gestion des erreurs dans Dart

Dans la transition vers une nouvelle technologie, nous perdons les outils habituels de développement. Dans certains cas, nous sommes obligés de supporter leur absence en raison de certaines limitations techniques, mais si possible, nous emportons les outils avec nous. Lors du développement d'applications Android, j'ai pris comme exemple une architecture propre proposée par Fernando Cejas. Comprenant les modèles de conception utilisés dans Flutter, j'ai décidé d'abandonner cette architecture au profit de BLoC. Je me suis rapidement habitué à ce modèle, il est très similaire à la MVVM avec laquelle j'ai travaillé plus tôt, mais je ne voulais pas accepter un détail. Lors de l'appel de méthodes de référentiel, j'ai dû intercepter des exceptions, les convertir en un certain type et, selon le type, créer l'état nécessaire. À mon avis, cela encombre le bloc et j'ai porté le type Either utilisé plus tôt dans les projets Android basés sur Fernando.

Soit provenait de langages de programmation fonctionnels. Il fournit la valeur de l'un des types possibles:

• Gauche (en cas d'échec);
• Bon (en cas de succès).

/// Signature of callbacks that have no arguments and return right or left value. typedef Callback<T> = void Function(T value); /// Represents a value of one of two possible types (a disjoint union). /// Instances of [Either] are either an instance of [Left] or [Right]. /// FP Convention dictates that: /// [Left] is used for "failure". /// [Right] is used for "success". abstract class Either<L, R> { Either() { if (!isLeft && !isRight) throw Exception('The ether should be heir Left or Right.'); } /// Represents the left side of [Either] class which by convention is a "Failure". bool get isLeft => this is Left<L, R>; /// Represents the right side of [Either] class which by convention is a "Success" bool get isRight => this is Right<L, R>; L get left { if (this is Left<L, R>) return (this as Left<L, R>).value; else throw Exception('Illegal use. You should check isLeft() before calling '); } R get right { if (this is Right<L, R>) return (this as Right<L, R>).value; else throw Exception('Illegal use. You should check isRight() before calling'); } void either(Callback<L> fnL, Callback<R> fnR) { if (isLeft) { final left = this as Left<L, R>; fnL(left.value); } if (isRight) { final right = this as Right<L, R>; fnR(right.value); } } } class Left<L, R> extends Either<L, R> { final L value; Left(this.value); } class Right<L, R> extends Either<L, R> { final R value; Right(this.value); } 

L'implémentation est très basique, inférieure aux solutions dans d'autres langues, mais fait face à sa tâche. J'utilise ce type comme résultat de toutes les méthodes de référentiel et la gestion des exceptions a été déplacée vers la couche de données. Cela élimine le besoin de constructions try / catch, ce qui rend le code plus lisible.

 class ContactBloc { final ContactRepository contactRepository; ContactBloc(this.contactRepository); @override Stream<ContactState> mapEventToState(ContactEvent event) async* { if (event is GetContactEvent) { yield LoadContactState(); try { var contact = contactRepository.getById(event.id); yield ContactIsShowingState(contact); } on NetworkConnectionException catch (e) { yield NetworkExceptionState(e); } catch (e) { yield UnknownExceptionState(e); } } } } abstract class ContactRepository { Future<Contact>getById(int id); } 

 class ContactBloc { final ContactRepository contactRepository; ContactBloc(this.contactRepository); @override Stream<ContactState> mapEventToState(ContactEvent event) async* { if (event is GetContactEvent) { yield LoadContactState(); final either = contactRepository.getById(event.id); if (either.isRight) { final contact = either.right; yield ContactIsShowingState(contact); } else { final failure = either.left; if (failure is NetworkFailure) yield NetworkFailureState(failure); if (failure is UnknownFailure) yield UnknownFailureState(failure); } } } } abstract class ContactRepository { Future<Either<Failure, Contact>>getById(int id); } 

En ce qui concerne la lisibilité, quelqu'un pourrait discuter. Peut-être que quelqu'un est habitué à essayer / attraper et aura raison à sa manière, pour la plupart c'est de l'arôme. Un avantage supplémentaire est que nous pouvons nous-mêmes définir la hiérarchie des échecs et revenir sur le côté gauche. Faisons un échec abstrait, rendons-le commun à toutes les fonctionnalités ServerFailure, NetworkFailure et à certaines fonctionnalités spécifiques de ContactFailure pour la fonctionnalité actuelle, avec les héritiers. Dans le bloc, nous saurons exactement à quel échec s'attendre.

L'inconvénient de l'implémentation de Failure on Dart est le manque de classes scellées comme dans kotlin, sinon il n'y aurait pas de if avec le casting. La langue est jeune, en plein développement et j'espère que le moment sera venu et que nous aurons des outils pour écrire les gestionnaires plus succinctement.

Quelqu'un peut ne pas aimer cette implémentation, peut la trouver inutile, mais je voulais juste vous présenter la possibilité d'une approche fonctionnelle de la gestion des erreurs dans Dart, bien que l'utilisation ne se soit pas révélée aussi élégante que dans d'autres langues.

Ressources:

Code source