Using Sass's @error, @warn, and @debug Directives

Sass debugging tools: @error, @warn and @debug commands

Sass provides three instructions to help developers debug code: @error, @warn and @debug. They are used to debug any value at any point in the code logic that needs help and find out the behavior of the code.

• @error Directive: This directive will completely stop the Sass compiler and send the text string to the compiler's output as a fatal error. It is great for validating parameters in mixin or functions and letting developers know what they are doing wrong or entering completely incompatible values.

• @warn Directive: This directive is less harmful than @error. It sends messages to the compiler for developers to read, but allows the compiler to do its job and write to all CSS. It works for deprecation notifications, or suggests that developers follow certain best practices.

• @debug Directive: This is the least invasive of the three feedback instructions. It prints the values ​​of any Sass expressions (variables, mathematical expressions, etc.) contained to the console for developers to view. It is perfect for personal debugging efforts.

Similar feedback mechanisms are very common in other programming languages, such as console.log() or alert() in JavaScript, var_dump() or print_r() in PHP, debug in Ruby, etc. . These functions allow you to debug any value and find out the behavior of the code at any point in the logic that needs help. inspect

Basic grammar and usage

The three instructions follow the same syntax:

<code class="language-sass">@directive "要输出的文本字符串";</code>

In fact, these three instructions can accept any type of value, not necessarily strings. This means you can warn, throw or debug maps, lists, numbers, strings – basically anything you want. However, since we often use these directives to provide context about the problem, we usually pass a string describing the situation.

If you need to insert the value of a variable into a string, you can use the standard Sass interpolation syntax

, and the value of the variable will be printed in the string: #{$variable}

<code class="language-sass">@error "抱歉，`#{$variable}` 不是 $variable 的有效值。";</code>

Note: Backticks (`) around interpolation are not required. You may want to include them because they provide developers with an obvious starting point/end point for variable content.

If the developer makes a mistake when using your Sass code, these directives will send the specified message to the compiler, which will display the message to the developer. For example, a GUI application (such as CodeKit) will display system notifications with errors. Some Grunt and Gulp notification packages can do this as well.

If developers compile using the command line (Sass, Compass, Grunt, or Gulp), the message may appear in their console (Terminal, iTerm2, Putty, etc.). If you write Sass online using Sassmeister or Codepen, you will only get limited feedback, but you may get inline notifications or text in the output window in the editor.

@error Instruction: Stop compiling immediately

The

Sass' @error directive stops the Sass compiler completely and sends the text string to the compiler's output as a fatal error. Use this directive when you need to send a message that stops the developer immediately and forces them to correct the error immediately. This is great for letting developers know what they are doing wrong or entering a completely incompatible value. Sass will contain any fatal error line numbers, including @error output. The @error directive is great for verifying parameters in a mixin or function.

Note: If your compiler is earlier than Sass 3.4 or LibSass 3.1, @error is not available. You can use this log() function to simulate @error in older versions of Sass.

@warn Instruction: issue a warning, but do not stop compiling

@warn Instructions are much less harmful than @error. It sends messages to the compiler for developers to read, but allows the compiler to do its job and write to all CSS. @error is suitable for correcting errors that completely break functions or mixins, while @warn is more suitable for deprecating notifications, or recommending developers to follow certain best practices.

Note: Sass developers compiled with the --quiet flag will not see the @warn output. If the developer absolutely needs to see the feedback sent by your Sass, rely on @error. @warn is rarely closed, but this is possible.

@debug Command: Debug output to console

Sass' @debug directive is the least invasive of the three feedback instructions. It prints the values ​​of any Sass expressions (variables, mathematical expressions, etc.) contained to the console for developers to view. It is not entirely useful in open source or team libraries. On the contrary, @debug is perfect for personal debugging. If you are in complex math operations and need to know what a variable currently contains, use @debug to find it.

Summary

Programming without feedback will be very bad. Fortunately, Sass has multiple instructions to send feedback to the compiler to help developers avoid errors, maintain standards, and troubleshoot advanced logic. You can use @error, @warn and @debug to provide time-saving feedback to yourself and anyone else using your code.

(The FAQs part is omitted because it is too long and does not match the pseudo-original goal. The FAQs part can be re-written as needed and integrated into the text to present in a more natural way.)

The above is the detailed content of Using Sass's @error, @warn, and @debug Directives. For more information, please follow other related articles on the PHP Chinese website!