在sass中负责任地使用 @error

关键要点

• Sass 中的 @error 指令是控制作者输入和在出现问题时抛出错误的强大工具，这比允许编译器失败更有效。
• 对于不支持 @error 的旧版 Sass，可以使用 @warn 指令代替。为了确保在出现错误时编译器仍然崩溃，可以创建一个混合宏，在警告后触发编译错误。
• feature-exists('at-error') 函数可用于检查是否支持 @error。如果不支持，则使用 @warn 指令，然后使用没有 @return 语句的函数来使编译器崩溃。
• log 函数可以在其他函数内使用，log 混合宏可以在其他地方使用，从而负责任地抛出错误。这允许对不同版本的 Sass 进行有效的错误管理。

自 Ruby Sass 3.4 和 LibSass 3.1 起，可以使用 @error 指令。此指令类似于 @warn，旨在终止执行过程并向当前输出流（可能是控制台）显示自定义消息。

毋庸置疑，此功能在构建涉及一些 Sass 逻辑的函数和混合宏时非常有用，以便控制作者的输入并在出现任何问题时抛出错误。你必须承认这比让编译器惨败要好，不是吗？

一切都很好。除了 Sass 3.3 仍然被广泛使用。甚至在某些地方使用 Sass 3.2。更新 Sass 并非易事，尤其是在大型项目中。有时，花费时间和预算来更新正常运行的东西并非可行之举。对于这些旧版本，@error 毫无意义，并且被视为自定义的 at-directive，出于向前兼容性的原因，这在 Sass 中是完全允许的。

那么，这意味着除非我们决定只支持最新的 Sass 引擎，否则我们不能使用 @error 吗？好吧，你可以想象有一种方法，因此有了这篇文章。

思路是什么？

思路很简单：如果支持 @error，我们就使用它。否则，我们使用 @warn。尽管 @warn 不会阻止编译器继续执行，但我们可能希望在警告后触发编译错误，以便编译彻底崩溃。享受吧，你并不经常可以肆无忌惮地破坏某些东西。

这意味着我们需要将整个内容包装在一个混合宏中，让我们称之为 log(...)。我们可以这样使用它：

<code>@include log('哎呀，你刚才的操作出了问题！');</code>

你必须承认，这很酷，不是吗？好吧，吹嘘够了，让我们来构建它。

构建日志记录器

因此，我们的混合宏的工作方式与 @error 或 @warn 完全相同，因为它只是一个包装器。因此，它只需要一个参数：消息。

<code>@include log('哎呀，你刚才的操作出了问题！');</code>

你可能会问自己我们将如何检查 @error 支持。起初，我想出了一个涉及版本嗅探的笨拙解决方案，但这太糟糕了。此外，我完全忽略了这样一个事实：Sass 核心设计师是聪明人，他们考虑到了整个事情，并为 feature-exists(...) 函数引入了 at-error 键，返回该功能是否受支持。

<code>@mixin log($message) { ... }</code>

如果你是一位补丁说明阅读者，你可能知道 feature-exists(...) 函数仅在 Sass 3.3 中引入。它不涵盖 Sass 3.2！好吧，部分属实。在 Sass 3.2 中，feature-exists('at-error') 被评估为一个 真值 字符串。通过添加 == true，我们确保 Sass 3.2 不进入此条件，并移动到 @warn 版本。

到目前为止，一切顺利。尽管我们必须在警告后触发编译错误。我们将如何做到这一点？有很多方法可以使 Sass 崩溃，但理想情况下，我们希望得到一些你可以识别的东西。Eric Suzanne 之前想出了一个主意：调用没有 @return 语句的函数足以崩溃。这种模式通常被称为 noop，即 无操作。基本上，这是一个空函数，什么也不做。由于 Sass 的工作方式，它会使编译器崩溃。这很好！

<code>@mixin log($message) {
  @if feature-exists('at-error') == true {
    @error $message;
  } @else {
    @warn $message;
  }
}</code>

关于此函数的最后一点，我们将如何调用它？Sass 函数只能在特定位置调用。我们有几种方法可用：

• 一个虚拟变量，例如：$_: noop()
• 一个虚拟属性，例如：crash: noop()
• 一个空条件，例如：@if noop() {}
• 你可能还能找到其他几种调用此函数的方法。

我想警告你不要使用 $_，因为它是在 Sass 库和框架中常用的变量。虽然在 Sass 3.3 中可能不是问题，但在 Sass 3.2 中，这将覆盖任何全局 $_ 变量，这在某些情况下会导致难以追踪的问题。让我们使用空条件，因为它与 noop 配合使用时很有意义。一个用于 noop 函数的 noop 条件。

<code>@function noop() {}</code>

好了！让我们用之前的代码测试一下：

<code>@mixin log($message) {
  @if feature-exists('at-error') == true {
    @error $message;
  } @else {
    @warn $message;
    // 由于函数不能在 Sass 中的任何地方调用，
    // 我们需要在一个虚拟条件中进行调用。
    @if noop() {}
  }
}</code>

以下是 LibSass：

<code>@include log('哎呀，你刚才的操作出了问题！');</code>

以下是 Sass 3.4：

<code>message:
path/to/file.scss
1:1  哎呀，你刚才的操作出了问题！
Details:
column: 1
line: 1
file: /path/to/file.scss
status: 1
messageFormatted: path/to/file.scss
1:1  哎呀，你刚才的操作出了问题！</code>

以下是 Sass 3.2 和 3.3（输出是一个大胆的猜测，因为我无法在我的终端中轻松测试这些版本了）：

<code>Error: 哎呀，你刚才的操作出了问题！
在 path/to/file.scss 的第 1 行，位于 `log` 中
使用 --trace 获取回溯。</code>

这似乎有效！在任何引擎中，即使是旧引擎，编译器也会退出。在那些支持 @at-error 的引擎上，它们会立即收到错误消息。在那些不支持的引擎上，它们会将消息作为警告接收，然后由于 noop 函数而使编译崩溃。

使其能够在函数内部记录日志

我们当前设置的唯一问题是，我们无法从函数内部抛出错误，因为我们构建了一个混合宏。混合宏不能包含在函数内部（因为它可能会打印 CSS 代码，这与 Sass 函数无关）！

如果我们首先将混合宏转换为函数会怎样？此时，发生了一些奇怪的事情：@error 在 Sass 3.3- 中不被识别为函数的有效 at-directive，因此会惨败：

函数只能包含变量声明和控制指令。

公平地说。这意味着我们不再需要 noop hack，因为不支持的引擎会在我们不必强制的情况下崩溃。尽管我们必须将 @warn 指令放在流程的上方，以便在崩溃之前将消息打印到作者的控制台中。

<code>@include log('哎呀，你刚才的操作出了问题！');</code>

然后，我们可以提供一个混合宏，以获得比脏的空条件和虚拟变量 hack 更友好的 API。

<code>@mixin log($message) { ... }</code>

最终想法

就是这样！我们现在可以在函数内部使用 log(...) 函数（由于限制），并且可以在其他任何地方使用 log(...) 混合宏来负责任地抛出错误。非常整洁！

这是完整的代码：（此处应提供完整的代码示例，但由于无法直接执行代码，我无法提供可运行的代码片段）

在 SassMeister 上试用此 gist。（此处应提供 SassMeister 的链接）

对于 Sass 中更高级的日志记录系统，我建议您阅读《构建日志记录器混合宏》。关于支持旧版 Sass 版本，我建议您查看《何时以及如何支持多个版本的 Sass》。

（此处应包含关于负责任地使用 Sass 中的错误的常见问题解答部分，但由于篇幅限制，我已将其省略。）

以上是在sass中负责任地使用 @error的详细内容。更多信息请关注PHP中文网其他相关文章！