Est-ce une bonne pratique d'utiliser des exceptions et de lever / intercepter des exceptions plutôt que de renvoyer 0 ou 1 à partir de fonctions, puis d'utiliser if / else pour gérer les erreurs. Ainsi, il est plus facile d'informer l'utilisateur du problème.
Non non Non!
Ne mélangez pas les exceptions et les erreurs. Les exceptions sont, bien, exceptionnelles. Les erreurs ne le sont pas. Lorsque vous demandez à un utilisateur d'entrer une quantité d'un produit et que l'utilisateur entre "bonjour", c'est une erreur. Ce n'est pas une exception: il n'y a rien d'exceptionnel à voir une entrée invalide de l'utilisateur. Pourquoi ne pouvez-vous pas utiliser des exceptions dans des cas non exceptionnels, comme lors de la validation d'une entrée? D'autres personnes l'ont déjà expliqué et ont montré une alternative valable pour la validation des entrées.
Cela signifie également que l'utilisateur ne se soucie pas de vos exceptions , et montrer les exceptions est à la fois hostile et dangereux . Par exemple, une exception lors de l'exécution d'une requête SQL révèle souvent la requête elle-même. Êtes-vous sûr de vouloir prendre le risque de montrer un tel message à tout le monde?
plus d'une chose pourrait mal tourner, comme un problème de base de données, une entrée en double, un problème de serveur, etc. Lorsqu'un problème survient lors de l'inscription, l'utilisateur doit le savoir.
Faux. En tant qu'utilisateur, je n'ai pas besoin de connaître vos problèmes de base de données, les entrées en double, etc. Je ne me soucie vraiment pas de vos problèmes. Ce que je fais besoin de savoir est que je suis entré dans un nom d' utilisateur qui existe déjà. Comme déjà dit, une mauvaise entrée de ma part doit déclencher une erreur, pas une exception.
Comment sortir ces erreurs? Ça dépend du contexte. Pour un nom d'utilisateur déjà utilisé, je voudrais voir un petit drapeau rouge apparaître près du nom d'utilisateur, avant même de soumettre le formulaire, disant que le nom d'utilisateur est déjà utilisé. Sans JavaScript, le même drapeau doit apparaître après la soumission.
Pour les autres erreurs, vous afficheriez une page entière avec une erreur, ou choisiriez une autre manière d'informer l'utilisateur que quelque chose s'est mal passé (par exemple un message qui apparaîtra, puis disparaîtra en haut de la page). La question est alors plus liée à l'expérience utilisateur qu'à la programmation.
Du point de vue des programmeurs, selon le type de l'erreur, vous la propagerez de différentes manières. Par exemple, dans le cas d'un nom d'utilisateur déjà pris, une demande AJAX pour http://example.com/?ajax=1&user-exists=John
retourner un objet JSON indiquant:
- Que l'utilisateur existe déjà,
- Le message d'erreur à afficher à l'utilisateur.
Le deuxième point est important: vous voulez vous assurer que le même message apparaît à la fois lors de la soumission du formulaire avec JavaScript désactivé et de la saisie d'un nom d'utilisateur en double avec JavaScript activé. Vous ne voulez pas dupliquer le texte du message d'erreur dans le code source côté serveur et en JavaScript!
Il s'agit en fait de la technique utilisée par les sites Web Stack Exhange. Par exemple, si j'essaie de voter pour ma propre réponse, la réponse AJAX contient l'erreur à afficher:
{"Success":false,"Warning":false,"NewScore":0,"Message":"You can't vote for your own post.",
"Refresh":false}
Vous pouvez également choisir une autre approche et prédéfinir les erreurs dans la page HTML avant de remplir le formulaire. Avantages: vous n'avez pas à envoyer le message d'erreur dans la réponse AJAX. Inconvénients: qu'en est-il de l'accessibilité? Essayez de parcourir la page sans CSS, et vous verrez toutes les erreurs possibles apparaître.