sass {}错误_如何有效使用Sass中的警告和错误

ゝ一纸荒年。 2022-12-03 09:09 430阅读 0赞

sass \{\}错误

*The following is a short extract from our book, [Jump Start Sass][], written by Hugo Giraudel and Miriam Suzanne. It’s the ultimate beginner’s guide to Sass. SitePoint Premium members get access with their membership, or you can buy a copy in stores worldwide.*

*以下是Hugo Giraudel和Miriam Suzanne所著《 [Jump Start Sass][] 》一书的摘录。* *这是Sass的终极入门指南。* *SitePoint Premium成员可以使用其成员身份进行访问，或者您可以在世界各地的商店中购买副本。*

Our incredible journey through Sass is slowly coming to an end, and so far you’ve been doing great! There’s one technical chapter left before we look at project architecture, and then you’ll be fully equipped to write Sass code in your own projects.

我们穿越Sass的令人难以置信的旅程正在慢慢结束，到目前为止，您一直做得很棒！ 在讨论项目体系结构之前，只剩下一章技术文章，然后您将有能力在自己的项目中编写Sass代码。

Now we’re going to look at warnings and errors. Both form a one-way communication system between the program (in this case, Sass) and the developer (you). If you’re wondering about the point of errors in the CSS world, remember that you already know the answer. Whenever you forget a semicolon or use a function incorrectly, Sass throws an error at you, explaining what you’ve done wrong and how you can fix it, thankfully! It would be a real pain to have to dig into the code to figure out what’s gone wrong.

现在我们来看看警告和错误。 两者都构成了程序(在本例中为Sass)与开发人员(您)之间的单向通信系统。 如果您想知道CSS世界中的错误点，请记住您已经知道答案了。 每当您忘记分号或不正确地使用函数时，Sass都会向您抛出错误，感谢您解释做错了什么以及如何解决。 必须深入研究代码找出问题所在，这确实是一个痛苦。

Sass has long provided a way to emit warnings from stylesheets, but it’s only recently added support to throw errors as well—and for good reason! Over the last few years, Sass has allowed authors to build complex systems to abstract difficult or repetitive patterns and concepts, such as grids. These systems must be able to communicate with authors, stopping the compilation process with a custom error message if anything ever goes wrong.

Sass很早就提供了一种从样式表发出警告的方法，但是它只是最近才添加了引发错误的支持，这是有充分理由的！ 在过去的几年中，Sass允许作者构建复杂的系统以抽象出困难或重复的模式和概念，例如网格。 这些系统必须能够与作者进行通信，并在出现任何错误时通过自定义错误消息停止编译过程。

Both warnings and errors are emitted in the current output channel. When compiling Sass by hand or by using a tool through a command line interface (CLI) such as [Grunt][] or [Gulp][], the output stream is the console. For tools that include a user interface, such as [Codekit][] or [Prepros][], it’s likely that they catch and display warnings and errors as part of their interface. Online playgrounds such as [CodePen][] and [SassMeister][] manage to catch errors but not warnings, so don’t be alarmed if you’re unable to test them in there.

警告和错误都会在当前输出通道中发出。 手动编译Sass或通过命令行界面(CLI)使用工具(例如[Grunt][]或[Gulp][] )编译Sass时，输出流是控制台。 对于包括用户界面的工具(例如[Codekit][]或[Prepros)][Prepros] ，它们很可能捕获并显示警告和错误作为其界面的一部分。 诸如[CodePen][]和[SassMeister之][SassMeister]类的在线游乐场可以捕获错误，但不能捕获警告，因此，如果您无法在其中进行测试，请不要惊慌。

## 警告事项 **(**Warnings**)** ##

As has been stated, the ability to emit warnings in Sass is not new. It’s possible to display messages or the value of any SassScript expression to the standard output stream through the `@warn` directive.

如前所述，在Sass中发出警告的能力并不新鲜。 可以通过`@warn`指令在标准输出流中显示消息或任何SassScript表达式的值。

A **warning** has no impact on the compilationprocess; it does not prevent compiling to pursue or change it in any way. Its only purpose is to display a message in the console.

**警告**对编译过程没有影响； 它不会阻止编译进行任何形式的追求或更改。 其唯一目的是在控制台中显示一条消息。

There are a lot of reasons to use warnings in Sass. Here are a couple, but you’re likely to find your own:

在Sass中使用警告有很多原因。 这是一对夫妇，但您很可能会找到自己的夫妇：

*  informing the user of an assumption made about the code in order to avoid surprise and hard-to-track bugs
    
    告知用户有关代码的假设，以避免出现意外和难以跟踪的错误
 *  advising about a deprecated function or mixin as part of a library or framework
    
    建议不推荐使用的函数或混合作为库或框架的一部分

Sending a warning is dead simple to do: start with the `@warn` directive, then state whatever it is. Warnings are usually made to provide some information and context, so they often feature a sentence explaining the situation. That being said, you don’t have to use a string; you can warn with a number, a list, a map—whatever. Here, we print a string:

发送警告非常简单：首先使用`@warn`指令，然后声明其`@warn` 。 通常会发出警告以提供一些信息和上下文，因此警告中通常带有解释情况的句子。 话虽如此，您不必使用字符串。 您可以使用数字，列表，地图等任何方式进行警告。 在这里，我们打印一个字符串：

@warn 'Uh-oh, something looks weird.';

Using a regular CLI client, this warning will emit the following output:

使用常规的CLI客户端，此警告将发出以下输出：

WARNING: Uh-oh, something looks weird.
             on line 1 of /Users/hgiraudel/jump-start-sass/warning.scss

Hey, that’s nice, isn’t it? Although this warning is far from helpful. It says that something looks weird but does not say what, why, or what can be done to stop it from looking weird. We’ll discuss how we can improve on warnings further on.

嘿，很好，不是吗？ 尽管此警告远没有帮助。 它说某事看起来很怪异，但没有说什么，为什么或做什么来阻止它看起来怪异。 我们将讨论如何进一步改善警告。

Let’s move on to a more serious example now that we know how to use he feature. Imagine we have a Sass custom function that attempts to convert a pixel value in `em` unit:

现在，让我们继续一个更严重的示例，因为我们知道如何使用他的功能。 想象一下，我们有一个Sass自定义函数，尝试以`em`单位转换像素值：

@function px-to-em($value, $base-font-size: 16px) {
      @return ($value / $base-font-size) * 1em;
    }
    
    // Usage
    .foo {
      font-size: px-to-em(42px); // 2.625em
    }

All good. Now, what happens when passing a unitless number—such as `42`—to the function? Maybe you’ve guessed it, but as it’s not quite obvious I’ll give you the answer:

都好。 现在，将无单位数字(例如`42`传递给函数时会发生什么？ 也许您已经猜到了，但是由于不太明显，我给您答案：

2.625em/px isn’t a valid CSS value.

This happens because you’re trying to perform a calculation between incompatible units (`px` and `em`). What we could do to circumvent this issue is assume the unitless value be expressed in pixels and convert it first:

发生这种情况是因为您试图在不兼容的单位( `px`和`em` )之间执行计算。 为了避免这个问题，我们可以做的是假设无单位值以像素表示并首先进行转换：

@function px-to-em($value, $base-font-size: 16px) {
      @if unitless($value) {
        @warn 'Assuming value `#{$value}` to be in pixels; attempting to convert it.';
        $value: $value * 1px;
    
      }
    
      @return ($value / $base-font-size) * 1em;
    }

The function is expecting a value expressed in pixels. We can still make it work with a unitless value; however, we cannot be sure that this is the expected behavior. We can only assume that it’s good enough.

该函数期望以像素表示的值。 我们仍然可以使其具有无价的价值。 但是，我们不能确定这是预期的行为。 我们只能假设它足够好。

Because we’re assuming what is the correct behavior for our function, it’s important to let the developer know what we’re doing and why. Otherwise it could lead to bugs that are hard to track, which is not what you should be aiming for.

因为我们假设函数的正确行为是什么，所以让开发人员知道我们在做什么和为什么这么做很重要。 否则，可能会导致难以跟踪的错误，这不是您应该针对的错误。

Another practical example would be to warn against the usage of a deprecated function or mixin. You might have already heard of or used [Bourbon][], a lightweight mixin library for Sass. Bourbon is actively maintained, and sometimes requires removing helpers from the library. To avoid suddenly breaking a person’s ode, Bourbon warns about future deprecations way before it actually removes mixins:

另一个实际的例子是警告不要使用不赞成使用的功能或混合。 您可能已经听说或使用过[Sour][Bourbon]的轻量级mixin库[Bourbon][] 。 Bourbon会得到积极维护，有时需要从库中删除助手。 为了避免突然破坏一个人的颂歌，Bourbon会在实际删除mixins之前警告有关将来的弃用方式：

@mixin inline-block {
      display: inline-block;
    
      @warn 'The `inline-block` mixin is deprecated and will be removed in the next major version release.';
    }

Clever! People who still use the `inline-block` mixin from Bourbon are aware that the library will remove it completely in the next version, so they know to start updating their codebase to remove the mixin.

聪明！ 仍然使用Bourbon的`inline-block`混合器的人们知道该库将在下一版本中将其完全删除，因此他们知道开始更新其代码库以删除混合器。

### `@warn`和`@debug`之间的`@debug` **(**The Difference between `@warn` and `@debug`**)** ###

You may or may not be familiar with the `@debug` directive, which prints the value of a SassScript expression to the standard output stream in the same fashion as `@warn`. You might be wondering why there are two features performing the same task, and what could possibly be the difference between the two.

你可能或可能不熟悉`@debug`指令，该打印SassScript表达式以相同的方式作为标准输出流的值`@warn` 。 您可能想知道为什么会有两个功能执行同一任务，以及两者之间可能有什么区别。

Well, there are two major differences between warning about a value and debugging a value. The first one is that warnings can be turned off using the `quiet` option. Debugs, on the other hand, will always be printed so that you remember to remove them when you’re done using them.

好吧，关于值的警告和调试值之间有两个主要区别。 第一个是可以使用`quiet`选项关闭警告。 另一方面，调试将始终被打印出来，以便您在使用完毕后记得将其删除。

The second difference is that warnings come with a **stack trace**—a report of the active stack framesat a certain point in time during the execution of a program. As aresult, you know from where they’re being emitted. Debugs only print thevalue, along with the line they were called in, but they offer no extrainformation.

第二个区别是警告带有**堆栈跟踪** \-在程序执行过程中某个时间点的活动堆栈帧的报告。 因此，您知道它们从何处发出。 调试仅打印该值以及它们被调用的行，但它们不提供任何额外信息。

The `@debug` directive can really come in handywhen you want to know what’s inside a variable, for instance:

当您想了解变量中的内容时，例如`@debug`指令可以派上用场：

@debug $base-font-size;

## 失误 **(**Errors**)** ##

Warnings and errors behave fairly similarly in Sass, so learningabout errors is going to be a breeze now that you are perfectly familiarwith warnings! The only difference between an **error** and a warning is—as you might have guessed—that the error stops the compilation process.

警告和错误在Sass中的行为相当相似，因此，既然您完全熟悉警告，那么对错误的了解将变得轻而易举！ 您可能已经猜到了， **错误**和警告之间的唯一区别是该错误会停止编译过程。

Using errors can be handy when validating parameters from mixins and functions, for instance. In the previous section, this worked even when the given argument was not exactly as expected, but we cannot (and should not) always do this. Most of the time, if arguments are invalid, it is better to throw an error so that the stylesheet author can fix the problem.

例如，在验证来自混入和函数的参数时，使用错误会很方便。 在上一节中，即使给定的参数与预期的不完全一样，该方法仍然有效，但是我们不能(也不应该)总是这样做。 在大多数情况下，如果参数无效，则最好抛出一个错误，以便样式表作者可以解决此问题。

You can throw an error using the `@error` directive. As for warnings, you can pass anything to this directive—not necessarily a string, although it usually makes more sense to provide a clear context. The argument (what you give to the `@error` directive) will be printed in the standard output stream, as well as a stack trace to give more insight about the problem. The compilation process will stop immediately.

您可以使用`@error`指令引发错误。 至于警告，您可以将任何内容传递给该指令-不一定是字符串，尽管提供清晰的上下文通常更有意义。 参数(您赋予`@error`指令的内容)将显示在标准输出流中，并显示堆栈跟踪以提供有关问题的更多信息。 编译过程将立即停止。

Let’s start with a Gandalf-approved error:

让我们从甘道夫批准的错误开始：

@error 'YOUUUUU! SHALL NOT. PASS.';

The output might depend on how you compile your stylesheets, as some tools catch and enhance the errors a certain way. Using the standard `sass` Ruby binary (gem), here’s how it looks:

输出结果可能取决于您如何编译样式表，因为某些工具会以某种方式捕获并增强错误。 使用标准的`sass` Ruby二进制(gem)，它的外观如下：

Error: YOUUUUU! SHALL NOT. PASS.
            on line 1 of /Users/hgiraudel/jump-start-sass/error.scss
      Use --trace for backtrace.

With the `trace` option, you can have the full stack trace from Sass itself, which isn’t that useful unless there’s an actual bug somewhere in the preprocessor. Hence why it is hidden as a default.

使用`trace`选项，您可以从Sass本身获取完整的堆栈跟踪，除非在预处理器中某处存在实际的错误，否则它没有什么用处。 因此，为什么默认将其隐藏。

Time to take a look at a *real* practical example. Let’s start by writing a small function to help accessing deeplynested values in maps, `map-deep-get(..)`:

时间来看看一个*真实的*实际例子。 让我们首先编写一个小的函数来帮助访问`map-deep-get(..)`嵌套值`map-deep-get(..)` ：

@function map-deep-get($map, $keys...) {
      @each $key in $keys {
        $map: map-get($map, $key);
    
        @if (type-of($map) == 'null') {
          @return $map;
        }
      }
    
      @return $map;
    }

Let’s enhance it with custom errors. But first, consider the following map and `map-deep-get(..)` call:

让我们通过自定义错误对其进行增强。 但首先，请考虑以下map和`map-deep-get(..)`调用：

$map: (
      'foo': (
        'bar': (
          'baz': 42
        )
      )
    );
    
    $value: map-deep-get($map, 'foo', 'bar', 'baz', 'qux');

As you may have noticed, the map lacks having a `qux` key nested in `baz`. Indeed, `baz` is not even associated with a map; instead, it is mapped to a number (`42`). If we try to execute this code, it will yield:

您可能已经注意到，地图缺少在`baz`嵌套的`qux`键。 的确， `baz`甚至与地图无关。 而是将其映射到数字( `42` )。 如果我们尝试执行此代码，它将产生：

Error: 42 is not a map for `map-get`
            on line 1 of /Users/hgiraudel/jump-start-sass/error.scss

Sass tries to perform a `map-get(..)` on `42` and emits an error because it cannot be done. While the error message is correct, it’s not very helpful. What would be helpful is to know the name of the key that caused the issue. We can do that!

Sass试图在`42`上执行`map-get(..)`并发出错误消息，因为它无法完成。 虽然错误消息是正确的，但不是很有帮助。 知道引起问题的密钥的名称将很有帮助。 我们能做到这一点！

We already check whether `$map` is `null` to perform an early return so as to avoid a compilation error if a key doesn’t exist. We can perform a second check to ensure that the map is actually a map, or we throw a meaningful error:

我们已经检查`$map`是否为`null`来执行早期返回，以避免在键不存在时避免编译错误。 我们可以进行第二次检查以确保地图实际上是地图，或者抛出有意义的错误：

@function map-deep-get($map, $keys...) {
      @each $key in $keys {
        $map: map-get($map, $key);
    
        // If `$map` does not contain the next key, return `null`
        @if type-of($map) == 'null' {
          @return $map;
        }
        
        // If `$map` is not a map, throw an error
        @if type-of($map) != 'map' {
          @error 'Key `#{$key}` is not associated with a map but a #{type-of($map)} (`#{$map}`).';
        }
      }
    
      @return $map;
    }

If we run our previous snippet again, here’s the output:

如果我们再次运行上一个代码段，则输出如下：

Error: Key `baz` is not associated with a map but a number (`42`).
            on line 1 of /Users/hgiraudel/jump-start-sass/error.scss

That’s much better! It’s now easy to fix our map and/or our function call thanks to the helpful error message.

那好多了！ 由于有用的错误消息，现在很容易修复我们的地图和/或函数调用。

## 包装东西 **(**Wrapping Things Up**)** ##

In this chapter, we learned how we can use Sass to emit warnings and throw errors in the standard output stream. This is usually the console, but it might vary depending on the way one compiles stylesheets.

在本章中，我们学习了如何使用Sass在标准输出流中发出警告并引发错误。 通常这是控制台，但可能会有所不同，具体取决于编译样式表的方式。

Warnings are helpful to emit non-critical messages to stylesheet authors—especially for framework and library authors—such as deprecation warnings or code assumptions. On the other hand, errors are used to prevent the compilation from pursuing, making it clear that the code needs to be fixed before going any further.

警告有助于将非关键消息发送给样式表作者(尤其是对于框架和库作者)，例如弃用警告或代码假设。 另一方面，使用错误来阻止进行编译，这清楚地表明，在进行任何进一步操作之前，都需要对代码进行修复。

All in all, warnings and errors are especially useful inside functions and mixins in order to validate user input, ensuring the stylesheets are being compiled as expected.

总而言之，警告和错误在函数和混合函数内部特别有用，可以验证用户输入，从而确保按预期方式编译样式表。

> 翻译自: [https://www.sitepoint.com/warnings-and-errors-in-sass/][https_www.sitepoint.com_warnings-and-errors-in-sass]

sass \{\}错误

[Jump Start Sass]: https://www.sitepoint.com/premium/books/jump-start-sass
[Grunt]: http://gruntjs.com/
[Gulp]: http://gulpjs.com/
[Codekit]: https://incident57.com/codekit/
[Prepros]: https://prepros.io/
[CodePen]: http://codepen.io/
[SassMeister]: http://sassmeister.com
[Bourbon]: http://bourbon.io/
[https_www.sitepoint.com_warnings-and-errors-in-sass]: https://www.sitepoint.com/warnings-and-errors-in-sass/