sass 引入sass
无论使用哪种语言,都应以简洁明了的方式处理错误,无论是为了最终用户还是下一个开发人员。 当您在网站上执行不正确的操作时,它不应该只是给您打上错误代码或失败的命令。 它应该向您发出关于发生了什么的明确信息,向您发出警告。
为其他开发人员编码时,这应该没有什么不同。 当您建立一个库,一个框架或只是一个团队工作时,您不是唯一使用代码的人。 很有可能,许多背景迥异的开发人员可能不得不使用您的代码,而他们不必深入研究源代码和曲折的心态以了解正在发生的事情。
这就是为什么您应该正确处理错误的原因。 即使在萨斯。 即使编译为CSS一样宽容的东西。 每当构建自定义函数或mixin时 ,都应始终确保一切正常,而在并非如此的情况下,应采用不同的方法。
我不了解您,但我真的不喜欢让Sass编译器失败。 我宁愿有一条很酷的小消息向我解释,我忘记了一个论点而不是面对:
长话短说:正确处理错误。 我会告诉你如何。
检查什么?
确保指定了所有参数
构建函数时要做的第一件事就是确保指定了所有参数。 不幸的是,如果传递给它的参数数量不正确,Sass甚至不会输入该函数。 幸运的是,编译器使用如下消息以漂亮的方式处理它: Mixin my-awesome-mixin缺少参数$ the-awesome-argument。 所以还不错。
如果您不想让它交由编译器处理,而是希望自己处理,可以通过为函数/ mixin中的所有参数指定默认参数来解决它。 最终用户不必每次都指定所有参数,这不仅更好,而且还允许您在所有情况下触发mixin /函数,并执行所需的操作。
确保论点有效
现在最重要的是确保所有参数均有效。 例如,如果您需要一种颜色,则必须确保开发人员实际上是在向函数传递颜色,而不是数字或字符串。 如果您需要三个值的列表,你应该检查长度,以确保有三个值,而不是两个或四个。
值得庆幸的是,Sass使用一堆默认函数(包括用于检查值的数据类型的type-of()
使执行此操作变得非常容易。 顺便说一句, Sass 3.4甚至应该引入 is-type-of($value, $type)
来解决()
测试类型的问题,该类型总是返回list
同时它也可以是map。
无论如何,即使为具有相当不错的Sass知识的开发人员编写代码时,也应注意函数的输入。
例如,当执行$value: $input + "px"
,基本上是在将数字(如果$input
是一个数字,显然)转换为字符串。 然后,如果您尝试执行$value * 2
,则Sass将抛出错误,因为您尝试将字符串相乘。 本文中有关此现象的更多信息。
...在功能上
使用自定义函数处理错误实际上很容易:检查需要检查的内容。 如果条件不匹配,则返回false
(或null
,请参见下文),并在@warn
Sass指令的帮助下警告用户。
@function add-10($number) {
@if type-of($number) != "number" {
@warn "`#{$number}` is not a number of `add-10`.";
@return false;
}
@return $number + 10;
}
在这种情况下(我同意,这很愚蠢),如果$number
参数不是数字,则该函数将返回false
并且将通过在终端上显示一条消息来警告用户它们传递了错误的参数: `SWAG`是不是`add-10`的数字 。
如果参数有效,则仅返回数字+10。简单为饼形。
...在混合中
在处理mixin时,它稍微复杂一些,因为您实际上并没有返回任何东西。 相反,您转储CSS规则。 要变通解决此问题,您需要声明一个布尔值,该布尔值用作有效性检查器。 请考虑以下示例:
@mixin module($name) {
// Initialize a validity checker boolean
$everything-okay: true;
// Check for argument validity
@if type-of($name) != "string" {
@warn "`#{$name}` is not a string for `module`.";
$everything-okay: false;
}
// If everything's still okay, dump mixin content
@if $everything-okay {
@content;
}
}
关于列表的一句话
如果要确保参数之一是其中包含多个项目的列表,则应始终测试长度而不是数据类型。 简而言之,Sass将所有值都视为单个元素列表,在某些情况下,您可以使用单个项目列表(实际上仍然是list
来找到自己。
另一方面,检查length
时一个潜在的问题是它也可以是map
。 确保绝对要面对多个值的列表的一种方法是这样做:
@if length($value) > 1 and type-of($value) != map {
// It is a list of multiple values
}
什么时候检查太多?
如果我完全对你诚实,我会说永远不会。 您永远都不能太小心,可能会检查应用程序的任何函数和混入参数。 但是,这可能不是必需的。 对于参数检查,我有一条黄金法则: 如果该值可能会使Sass编译器崩溃,则应该检查它 。
这意味着,如果您有一个mixin接受直接用作CSS属性值的参数,那么我认为积极检查它们毫无意义。 最坏的情况是这些值将被转储到CSS输出中,从而导致无效CSS,浏览器将无法理解。 除了加载几个额外的字节外,不会有太大危害。
例如,考虑以下混合:
@mixin size($width, $height: $width) {
width: $width;
height: $height;
}
现在考虑以下用法:
.element {
@include size(10, "string");
}
生成CSS将是:
.element {
width: 10;
height: "string";
}
任何浏览器都将拒绝两个属性,因为它们的值无效。 没什么大不了的。
处理深层嵌套函数中的错误
随着我们刚才看到的,你应该能够正确地处理可能出现的错误的99%,但是有它越来越难以跟上萨斯的情况:有错误从从一个函数调用的函数打交道时,从一个叫功能...
我在编写SassyJSON时遇到了这个问题, SassyJSON是用Sass编写的JSON解析器。 基本上,您将JSON字符串传递给json-decode
函数,然后将其中_json-decode--value
到_json-decode--value
函数,然后再将其中_json-decode--*
到_json-decode--*
函数,具体取决于要解析的值的类型。 无论如何,对于我来说,嵌套三个,四个,甚至五个函数调用并不罕见。
不幸的是,在这种情况下,没有干净的方法来停止执行。 您必须通过手动检查每个级别的函数返回值来使错误上升到更高级别。 例如,如果您在最深层函数中有错误,则应将false返回给调用函数,然后调用函数应检查该值,意识到它为false
,因此将false返回给上层函数,依此类推,直到达到最高值为止然后停止执行。
处理起来很痛苦,但别无选择。 话虽这么说,如果您必须嵌套多个级别的函数,那么我会说您没有正确使用Sass。
发生错误时应返回什么
每当出现问题时,您都可以返回各种值,其中false
和null
是最受欢迎的值。 我想如果您来自JavaScript背景,则可以返回-1
或void 0
。 我想您也可能会返回类似ERROR::{{ CODE }}
尽管那样会使检查故障变得更加复杂。
我过去常常返回false
因为这说明了事实:这是错误的。 但是,这可能是应该返回布尔值的函数的问题。 你怎么知道如果函数返回false
,因为结果已被评估为false
,或false
,因为出现了错误?
因此,您可以决定选择另一个值。 有一个有趣的事情null
:用的值CSS属性null
不会被编译到源。 基本上,这意味着如果您将Sass函数用作CSS属性的值并且出了点问题,Sass编译器将简单地忽略CSS属性。
我认为这样的事情实际上有点好:
.element {
background: get-color-from-theme('admin');
}
如果get-color-from-theme
函数的设计经过精心设计,则应确保存在admin
主题并将其实际绑定到颜色值。 如果admin
不存在,则该函数将返回null
,这将导致background: null
。 这将使Sass在将文件编译为CSS时忽略规则。
需要throw()
函数
大多数语言都有throw
函数或指令。 通常,此函数将错误消息或异常作为唯一参数接受,并且只要有错误,就停止脚本执行以显示此消息(在控制台中或其他内容)。 例如,在JavaScript中,您可以执行以下操作:
if (typeof myVariable === "undefined") {
throw new userException("`myVariable` should be defined");
}
不幸的是,Sass没有这个。 基本上,Sass中绝对没有办法停止执行函数或mixin。 您可以构建一个,但是实际上并不能停止该函数,它只会返回false并记录一条消息。
@function throw($log) {
@warn $log;
@return false;
}
您可以使用throw()
函数,而不是每次都手动编写@warn
指令和@return false
,但是请记住它不会产生任何魔力,也不会阻止脚本运行。 它只是返回false并记录一条错误消息。
话虽这么说,已经向Sass维护者多次询问了throw
指令,并且看来他们已经同意实施@error
指令并不会很糟糕,该指令会根据问题#747中断当前范围的执行。 也许对于3.4,我不确定。
最后的想法
无论如何执行,都应始终检查函数和混合输入,而不要让编译器崩溃,因为它遇到了意外情况。 作为一名开发人员,我宁愿拥有一个干净的日志,什么也不输出,而不是一个巨大的堆栈跟踪,但是那又不是我。
作为一个实时示例,我建议您看看我前一段时间构建的一个小按钮库 。 核心mixin的大部分代码是参数检查和错误处理。 它使mixin看起来很拥挤,但是我认为这对于将要使用代码的开发人员至关重要。
最后,只要确保您想出适合您和您的团队的东西,就可以了。
翻译自: https://webdesign.tutsplus.com/tutorials/an-introduction-to-error-handling-in-sass--cms-19996
sass 引入sass