68747470733a2f2f692e696d67666c69702e636f6d2f3178377877312e6a7067

Le sujet de la gestion des erreurs amène souvent discussions et incompréhensions. Du coup, j’ai décidé de tester plusieurs solutions. J’attends votre avis !

Commentaires

La séparation en deux types d'exceptions (BusinessException et Technical Exception) me fait penser à la manière de traiter les erreurs en Objective-C qui distinguent deux concepts :

- Les exceptions (NSException), semblable au exceptions Java, mais qui doivent être utilisées seulement pour les erreurs de programmation, tel qu'un accès à l'index d'un tableau hors de ses limites, ou un argument de méthode invalide.

- Les erreurs niveau utilisateur (NSError) pour les erreurs d'exécution, tel que l'accès à un fichier introuvable ou un formulaire non valide ;)
Cette approche ressemble à ta seconde propositions mais en passant l'objet erreur par référence à la méthode plutôt qu'en paramètre de retour, la signature de la méthode reste donc cohérente.
Malheureusement il n'est pas possible en Java de passer un objet par référence, donc l'implémentation d'une tel gestion nécessiterait de créer l'objet erreur avant de le passer à la méthode.
Aussi il n'existe pas d'équivalent à l'objet NSError, mais il doit être possible de créer une classe semblable en Java.

Si vous intéresse vous trouverez pleins d'informations supplémentaires dans ce guide sur comment utiliser et créer l'objet NSError :
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/CreateCustomizeNSError.html#//apple_ref/doc/uid/TP40001806-CH204-BAJIIGCC

Enfin si les exceptions sont si décriées et si Apple a choisi ce design c'est il me semble pour ces deux principaux problèmes qui sont; les latences d'exécutions, et les possibilités d'aboutir rapidement à un code mal architecturé (car comme dirais mon oncle « Un grand pouvoir implique de grandes responsabilités »)

Il y a 8 mois
Vous devez vous inscrire ou vous connecter pour poster un commentaire