Share
Quelle que soit la langue utilisée, les erreurs doivent être gérées de manière claire et simple, que cela profite à l'utilisateur final ou au développeur suivant. Lorsque vous effectuez une action incorrecte sur un site, il ne devrait pas simplement vous attribuer un code d'erreur ou une commande défaillante. Il devrait vous avertir avec un message explicatif sur ce qui se passe.
Cela ne devrait pas être différent lors du codage pour d'autres développeurs. Lorsque vous construisez une bibliothèque, un cadre ou travaillez simplement en équipe, vous n'êtes pas le seul à utiliser le code. Très probablement, de nombreux développeurs ayant des antécédents très différents devront peut-être utiliser votre code, et ils ne devraient pas avoir à fouiller dans la source ni dans les rebondissements de votre esprit pour comprendre ce qui se passe..
C'est pourquoi vous devez gérer les erreurs correctement. Même à Sass. Même quand il compile quelque chose d'aussi permissif que CSS. Chaque fois que vous créez une fonction personnalisée ou un mixin, vous devez toujours vous assurer que tout fonctionne comme prévu. Si ce n'est pas le cas, vous devez choisir un autre chemin..
Je ne sais pas pour vous, mais je n'aime vraiment pas laisser le compilateur Sass échouer. Je préférerais avoir un petit message cool m'expliquant que j'ai oublié un argument plutôt que d'affronter:
Longue histoire courte: gérer les erreurs correctement. Je vais te montrer comment.
Une des premières choses à faire lors de la création d’une fonction est de s’assurer que tous les arguments sont spécifiés. Malheureusement, Sass n'entrera même pas dans la fonction si le nombre d'arguments transmis est incorrect. Heureusement, le compilateur le gère de manière élégante avec un message du type: Mixin my-awesome-mixin manque l'argument $ the-awesome-argument. donc ce n'est pas si mal.
Si vous ne voulez pas laisser cela entre les mains du compilateur et que vous préférez le gérer vous-même, vous pouvez le contourner en spécifiant des paramètres par défaut pour tous les arguments de la fonction / mixin. Non seulement il est préférable que l’utilisateur final ne spécifie pas tout arguments chaque une seule fois, mais cela vous permet également de déclencher le mixin / la fonction dans tous les cas, et de faire tout ce qui doit être fait.
Le plus important est maintenant de s’assurer que tous les arguments sont valides. Par exemple, si vous avez besoin d'une couleur, vous devez vous assurer que le développeur passe bien une couleur à la fonction et non un nombre ou une chaîne. Si vous avez besoin d’une liste de trois valeurs, vous devriez vérifier la longueur pour vous assurer que sont trois valeurs, pas deux ou quatre.
Heureusement, Sass rend cela très facile avec un tas de fonctions par défaut, y compris Type de() vérifier le type de données d'une valeur. À propos, Sass 3.4 devrait même introduire is-type-of ($ valeur, $ type) pour contourner la question du type de test () qui revient toujours liste alors que cela peut être aussi une carte.
Quoi qu'il en soit, même lorsque vous écrivez un morceau de code pour les développeurs connaissant sassement Sass, vous devez être particulièrement attentif à la saisie de vos fonctions..
Par exemple, en faisant $ value: $ input + "px", vous lancez essentiellement un numéro (si $ input est un nombre, évidemment) à une chaîne. Ensuite, si vous essayez de faire $ valeur * 2, Sass lancera une erreur parce que vous essayez de multiplier une chaîne. Plus d'informations sur ce phénomène dans cet article.
Le traitement des erreurs dans le cas d'une fonction personnalisée est en fait assez simple: vous vérifiez tout ce qui doit être vérifié. Si la condition ne correspond pas, vous revenez faux (ou nul, voir ci-dessous) et avertissez l’utilisateur avec l’aide du @prévenir Directive Sass.
@function add-10 ($ number) @if type-of ($ number)! = "number" @warn "'# $ number' n'est pas un nombre de 'add-10'."; @retour faux; @return $ number + 10;
Dans ce cas (assez idiot je suis d’accord), si le numéro $ l'argument n'est pas un nombre, la fonction retournera faux et l'utilisateur sera averti qu'il a passé un argument incorrect par un message apparaissant dans son terminal: 'SWAG' n'est pas un nombre pour 'add-10'.
Si l'argument est valide, il renvoie simplement le nombre + 10. Simple comme bonjour.
Lorsque vous travaillez avec un mixin, c'est un peu plus compliqué, car vous ne retournez pas réellement quelque chose. à la place, vous videz les règles CSS. Pour contourner le problème, vous devez déclarer un booléen servant de vérificateur de validité. Veuillez considérer l'exemple suivant:
@mixin module ($ name) // Initialise un vérificateur de validité booléen $ tout-okay: true; // Vérification de la validité des arguments @if type-of ($ name)! = "Chaîne" @warn "'# $ nom' n'est pas une chaîne pour 'module'."; $ tout va bien: faux; // Si tout va bien, dump mixin content @if $ everything-okay @content;
Lorsque vous voulez vous assurer que l'un des arguments est une liste contenant plusieurs éléments, vous devez toujours tester la longueur plutôt que le type de données. Pour le dire simplement, Sass traite toutes les valeurs en tant que listes d’élément unique et, dans certains cas, vous pouvez vous retrouver avec une liste d’élément unique qui reste en réalité un élément. liste.
D'autre part, un problème potentiel lors de la vérification de la longueur est-ce que ça peut être un carte ainsi que. Une façon de vous assurer que vous faites face à une liste de valeurs multiples est de procéder comme suit:
@if length ($ value)> 1 et type-of ($ value)! = map // C'est une liste de plusieurs valeurs
Si je suis tout à fait honnête avec vous, je dirais jamais. Vous ne pouvez jamais être trop prudent et pouvez probablement vérifier n'importe quel argument de n'importe quelle fonction et n'importe quel mixin de votre application. Cependant, ce n'est probablement pas nécessaire. J'ai une règle d'or en matière de vérification d'arguments: si la valeur est susceptible de faire planter le compilateur Sass, alors vous devriez l'avoir cochée.
Cela signifie que si vous avez un mélange acceptant des arguments qui sont directement utilisés comme valeurs pour les propriétés CSS, je ne pense pas qu'il soit inutile de les vérifier de manière agressive. Le pire des cas est que ces valeurs soient vidées dans la sortie CSS, ce qui entraîne un code CSS non valide qui ne sera pas compris par le navigateur. Mis à part quelques octets supplémentaires chargés, il n'y aura pas beaucoup de mal.
Par exemple, considérons le mixin suivant:
@mixin size ($ width, $ height: $ width) width: $ width; hauteur: $ hauteur;
Et maintenant, considérons l'utilisation suivante:
.element @include size (10, "chaîne");
Le CSS résultant sera:
.élément largeur: 10; hauteur: "chaîne";
Tout navigateur refuse simplement les deux propriétés car leurs valeurs ne sont pas valides. Pas grand chose.
Avec ce que nous venons de voir, vous devriez être capable de gérer correctement 99% des erreurs possibles, cependant est un cas où il devient de plus en plus difficile de suivre Sass: lorsqu'il s'agit d'erreurs d'une fonction appelée à partir d'une fonction appelée à partir d'une fonction…
J'ai fait face à cette même chose en écrivant SassyJSON, un analyseur JSON écrit en Sass. Fondamentalement, vous passez une chaîne JSON au json-décoder fonction, qui le transmet au _json-decode - valeur fonction, qui le relaie ensuite à un _json-decode - * fonction en fonction du type de la valeur qui est analysée. Quoi qu’il en soit, il n’était pas rare pour moi que trois, quatre, voire cinq appels de fonction soient imbriqués les uns dans les autres.
Malheureusement, dans un tel cas, il n’existe aucun moyen propre d’arrêter l’exécution. Vous devez faire remonter vos erreurs jusqu'au niveau supérieur en vérifiant manuellement le retour de la fonction à chaque niveau. Par exemple, si vous rencontrez une erreur dans la fonction la plus profonde, elle doit renvoyer false à la fonction appelante, qui doit ensuite vérifier cette valeur et réaliser que faux, donc retourne false à la fonction supérieure, et ainsi de suite jusqu'à atteindre la plus haute fonction qui arrête ensuite l'exécution.
C'est assez pénible à gérer mais il n'y a pas d'autre choix. Cela étant dit, si vous devez imbriquer plusieurs niveaux de fonctions, je dirais que vous n'utilisez pas Sass correctement.
Chaque fois que quelque chose ne va pas, vous pouvez renvoyer diverses valeurs, faux et nul étant les plus populaires. Je suppose que tu pourrais revenir -1 ou vide 0 si vous venez d'un fond JavaScript. Je suppose que vous pourriez aussi retourner quelque chose comme CODE D'ERREUR bien que cela rende le chèque pour un échec légèrement plus compliqué.
J'ai l'habitude de revenir faux parce que cela parle pour lui-même: c'est faux. Cependant, cela pourrait être un problème avec les fonctions qui sont supposées retourner un booléen. Comment sauriez-vous si la fonction retourne faux parce que le résultat a été évalué à faux, ou faux parce qu'il y a eu une erreur?
Ainsi, vous pouvez décider de choisir une autre valeur. Il y a une chose intéressante avec nul: une propriété CSS avec une valeur de nul ne sera pas compilé à la source. En gros, cela signifie que si vous utilisez une fonction Sass comme valeur pour une propriété CSS et que quelque chose ne va pas, la propriété CSS sera simplement omise par le compilateur Sass..
Je pense que c'est plutôt sympa pour quelque chose comme ça:
Accentsconagua
.element background: get-color-from-theme ('admin'); Si la fonction get-color-from-theme bien conçu, il convient de s’assurer que le admin le thème existe et est en fait lié à une valeur de couleur. Si admin n'existe pas, alors la fonction reviendrait nul ce qui entraînerait fond: null. Sass omettra la règle lors de la compilation du fichier en CSS..
jeter() Une fonctionLa plupart des langues ont un jeter fonction ou directive. Habituellement, cette fonction accepte un message d'erreur ou une exception comme seul argument et arrête simplement l'exécution du script pour afficher ce message (dans la console ou quelque chose du genre) en cas d'erreur. Par exemple en JavaScript, vous pouvez faire quelque chose comme ceci:
if (typeof myVariable === "undefined") lève une nouvelle exception userException ("'maVariable" doit être défini "); Malheureusement, Sass n'a pas cela. En gros, il n’ya absolument aucun moyen d’empêcher une fonction ou un mixin de s’exécuter. Vous pouvez en créer un, mais cela n’arrêterait pratiquement pas la fonction, il renverrait simplement false et consignera un message..
@function throw ($ log) @warn $ log; @retour faux;
Au lieu d'écrire manuellement le @prévenir directive et la @retour false chaque fois, vous pouvez utiliser le jeter() Cependant, son fonctionnement n’a aucun effet magique et n’empêche pas l’exécution du script. Il retourne simplement 'false' et enregistre un message d'erreur.
Cela étant dit, avoir un jeter La directive a été demandée plusieurs fois aux responsables de Sass et il semble qu'ils aient convenu qu'il ne serait pas si mauvais de mettre en œuvre un @Erreur directive qui romprait l'exécution de la portée actuelle selon le problème # 747. Peut-être pour 3.4, je ne suis pas sûr.
Quelle que soit la façon dont vous le faites, vous devez toujours vérifier les entrées de fonction et de mixage plutôt que de laisser le compilateur planter car il a rencontré quelque chose d'inattendu. En tant que développeur, je préférerais avoir un journal vierge et aucune sortie plutôt qu'une trace de pile énorme, mais encore une fois, ce n'est pas moi.
Par exemple, je vous suggère de regarder une petite bibliothèque de boutons que j'ai construite il y a quelque temps. La plupart du code du core mixin est la vérification des arguments et la gestion des erreurs. Le mixin semble encombré, mais je pense que c'est essentiel pour les développeurs qui utiliseront le code.
En fin de compte, assurez-vous de proposer quelque chose qui vous convient, à vous et à votre équipe, et tout ira bien.
