Loading...

error-checkingAs we move through our dive into SASS, we are using programming fundamentals that span from basic variable usage through mixins and placeholders. Our styles have become more complicated and much more functional. As the code we write increases in complexity, we tend to see errors during compilation. This article will address ways to check for errors and potential mistakes in our usage of these advanced topics.

Error checking is available is nearly all modern languages and SASS is no exception. SASS 3.1 introduced three directives for providing feedback without relying on your compiler to throw a Fatal error. These directives allow you to select the severity of your “error”. Error isn’t completely correct, as an error would indicate that there is a problem that causes your code to stop compilation. Instead, we should call these useful tools feedback directives; @error, @warn, and @debug. 

@error is the most extreme of the feedback directives. Implementing @error will cause compilation to halt and display an error message in the compiler log (or elsewhere depending on your compiler and settings). When the compiler hits @error, everything stops, no more compiling happens and your stylesheet output is either partially complete or empty. Think of this as the hammer-down method for SASS. @error is used to ensure that a specific value or type is used correctly. 

Let’s take a look at an example.

 
<code>


/* Our Mixin */

@mixin widget($font-size: 10px) {

 display: block;

 font-size: rem-calc($font-size);

}


.test-widget {

 @include widget();

}


</code>
 
This is a great example of using a mixin. We set a default value for font-size and we are using that value for our font-size. Ideally, this will work great. However, what if later on you use the widget mixin and pass in a non-numeric value. Depending on your settings, the compilation may run without issue but now are styles are not ideal. Let’s look at an example.
 
<code>


/* Our Mixin */

@mixin widget($font-size: 10px) {

 display: block;

 font-size: rem-calc($font-size);

}


.test-widget {

 @include widget(blue);

}


</code>
 
If we inspect our element we can see that we now have font-size: blue. That’s not what we want. Now we can make a decision on priority. In our example, it is likely that we will want to use @error to prevent breaking changes. Let’s first check to see if font-size is a number. We can do that using an if statement and the type_of() function. If the if statement returns false, we will throw an error and stop compilation.
 
<code>

/* Our Mixin */

@mixin widget($font-size: 10px) {


 @if type-of($font-size) != number {

   @error "#{$font-size} is not a number";

 }


 display: block;

 font-size: rem-calc($font-size);

}


.test-widget {

 @include widget(blue);

}


</code>
 
In our output log or file, we can see the error followed by a backtrace: 
Error: _sample.scss

Error: blue is not a number

       on line 4 of _sample.scss

>>     @error "#{$font-size} is not a number";

  -----^
 
This error shows us the file that our error occurred in, the line number and our supplied value for $font-size. This is great for debugging a critical error. 
 
That’s great but what if we don’t want our compiler to stop because of a non-crucial mistake? That’s where @warn and @debug come in. While very similar there are some minor differences between the two. 
 
The output location for @warn and @debug can be modified separately to give you more control over when and how these messages are seen. By default, the largest difference comes in the amount of data supplied to your log.
 
<code>


/* Our Mixin */

@mixin widget($font-size: 10px) {

 @if type-of($font-size) != number {

   @warn "#{$font-size} is of type: #{type-of($font-size)}";

   @debug "You should probably change this";

 }


 display: block;

 font-size: rem-calc($font-size);

}


.test-widget {

 @include widget(blue);


 color: black;

}


</code>


WARNING: blue is of type: color

Backtrace:

_sample.scss:4, in mixin `widget`

_sample.scss:14


_sample.scss:5 DEBUG: You should probably change this
 
Check back soon for an article discussing how to modify SASS output, hiding and showing @error, @warn, @debug based on context and more.
 
Have a question? Let us know!