En Java, tu es obligé d'attraper la plupart des exceptions.
Pas en Groovy. Dans le cadre d'un serveur d'application qui intègre un connecteur FreeCAD, Solr, LibreOffice, sans compter la gestion des données persistantes, la problématique de la sécurité, la validation des données... c'est peut-être un avantage. Tu n'as certainement pas envie de traiter tous les cas de figure si le formulaire contient un fichier à uploader et peu lever un nombre d'exception conséquent lors de la sauvegarde de ce formulaire.
D'ailleurs, vu par l'utilisateur, le cas ou une exception est non catchée sur un serveur d'application c'est que la requête retourne un code 501 et que les données persistantes ne sont pas modifiées. C'est donc "limité". L'application continue de tourner. C'est difficile d'anticiper un comportement correcte suite à certaines erreurs. Moi, c'est mon tél ou ma boite mail qui vont recevoir les insultes, personne ne va en mourir dans mon cas (à moins d'être susceptible ou dépressif). Mais je ne vois pas comment on peut faire mieux.
Il n'y a quasiment pas de try ... catch dans notre code, excepté pour ne pas interrompre l'initialisation du serveur si l'erreur est tolérable, lors de l'initialisation des services, lorsque le service est initialisé AVANT son utilisation (pas de lazy-init). Bref, au final, je n'ai pas quasiment pas de code de gestion d'erreur, mais nombre d'erreur soit sont traitées par le framework lui-même, soit on ne peut rien en faire et seulement prévenir l'administrateur...
[^] # Re: Kamoulox !
Posté par YBoy360 (site web personnel) . En réponse au journal Golang, oops you did it again. Évalué à 3.
Pas en Groovy. Dans le cadre d'un serveur d'application qui intègre un connecteur FreeCAD, Solr, LibreOffice, sans compter la gestion des données persistantes, la problématique de la sécurité, la validation des données... c'est peut-être un avantage. Tu n'as certainement pas envie de traiter tous les cas de figure si le formulaire contient un fichier à uploader et peu lever un nombre d'exception conséquent lors de la sauvegarde de ce formulaire.
D'ailleurs, vu par l'utilisateur, le cas ou une exception est non catchée sur un serveur d'application c'est que la requête retourne un code 501 et que les données persistantes ne sont pas modifiées. C'est donc "limité". L'application continue de tourner. C'est difficile d'anticiper un comportement correcte suite à certaines erreurs. Moi, c'est mon tél ou ma boite mail qui vont recevoir les insultes, personne ne va en mourir dans mon cas (à moins d'être susceptible ou dépressif). Mais je ne vois pas comment on peut faire mieux.
Il n'y a quasiment pas de try ... catch dans notre code, excepté pour ne pas interrompre l'initialisation du serveur si l'erreur est tolérable, lors de l'initialisation des services, lorsque le service est initialisé AVANT son utilisation (pas de lazy-init). Bref, au final, je n'ai pas quasiment pas de code de gestion d'erreur, mais nombre d'erreur soit sont traitées par le framework lui-même, soit on ne peut rien en faire et seulement prévenir l'administrateur...