Handling Errors with @error and @warn3:51 with Guil Hernandez
Providing feedback to developers when something goes wrong in their code is important. Sass offers directives that provide feedback to the compiler and help you avoid mistakes. In this video, we'll use the @error and @warn directives to make sure our media query mixin arguments are valid.
Code doesn't always run smoothly on your first, even second or third attempt. 0:00 Getting used to working with SAS and writing it well takes time and practice. 0:04 So it's common to make lots of mistakes along the way. 0:08 Even when you become a SAS pro there will be times when parts of your code 0:10 just won't work. 0:14 So in these final videos we'll look at the way SAS helps you handle errors and 0:15 debug code in the browser and console. 0:18 Providing feedback to developers when something goes wrong in their code is 0:20 crucial in any programming language. 0:24 So SAS offers three directives that provide feedback to the compiler and 0:26 help you avoid mistakes error, warn, and debug. 0:29 I'm only going to cover error and warn in this video, but 0:33 you can learn more about the debug directive in the teacher's notes. 0:37 So the error and warn directives are incredibly useful for making sure function 0:40 and mixin arguments are valid and that you're following best practices. 0:44 For example, one problem with our media query mixin is that it's error-prone and 0:48 fails without a warning. 0:52 For instance, if you misspell or 0:53 provide an incorrect breakpoint name, Everything comes to a halt. 0:55 The compiler stops running and outputs the error Invalid null operation null 1:01 lt 576 in the browser, console, and output CSS. 1:07 So this message is not very helpful because it provides no warning or 1:14 explanation of what caused the error. 1:19 So the error and warn directives give you the ability to output 1:22 custom messages that help you track down errors and fix mistakes in your code. 1:27 So over in the mixins partial let's add a condition 1:31 to the media query mixin that checks for invalid values. 1:35 And we'll make it the first condition using the if directive to check 1:39 if the value is equal to null or if it's invalid. 1:44 Inside the curly braces we'll use the error directive 1:50 to print a custom error message within a set of quotes. 1:53 So inside the quotes I'll use interpolation syntax to insert the value 1:58 of break in to the error message which will read is not a valid breakpoint name. 2:02 So now let's not forget to update our original if condition here to an else if. 2:13 Give this a save. 2:23 And if you the pass the media query mixin an invalid value for break. 2:24 So for example, fooo. 2:28 Once you save your changes the compile stops running and the error directive 2:31 outputs the message Error fooo is not a valid breakpoint name in the browser, 2:36 console output, as well as the stack trace in style.css. 2:42 So it traces back to the source of the error to help make debugging easier. 2:47 While the error directive immediately stops the compiler and 2:52 forces you to correct the mistake, the warn directive is less strict. 2:57 Warn outputs a warning message but allows the compiler to keep running. 3:03 So if I change this to warn, save, the compiler keeps running, but 3:07 over in the console you'll see that it outputs the message, 3:12 warning foooo is not a valid breakpoint name. 3:16 So the error directive is useful for validating arguments to mixins and 3:21 functions. 3:26 It notifies developers when they've entered invalid data. 3:27 And use warn to inform developers of deprecations in the code like, 3:31 unnecessary vendor prefixes or to suggest that they follow certain best practices on 3:35 a project, like using m-values instead of pixels. 3:40 I've posted links to more examples of how to use error and 3:46 warn in the teacher's notes. 3:49
You need to sign up for Treehouse in order to download course files.Sign up