Sass @error stops compilation and prints a clear message (plus a stack trace) when something is wrong. This page covers syntax, validating mixin/function arguments, type and range checks, how errors differ from @warn / @debug, and five practical examples.
01
Stop
@error
02
Message
Clear string
03
Guards
Args & types
04
Trace
Call stack
05
Vs warn
Hard vs soft
06
Practice
5 examples
Concept
What Is @error?
Official docs: when mixins and functions take arguments, you usually want to ensure those arguments have the types and formats your API expects. If they are not, the user needs to be notified and your mixin/function needs to stop running.
Sass makes this easy with @error, written @error <expression>. It prints the value of the expression (usually a string) along with a stack trace, then stops compiling and tells your build system that an error occurred.
No CSS is emitted for a failed compile once @error runs.
Message formatting and stack traces vary by Sass implementation and build tool.
Interpolate values with #{$var} so the bad input shows up in the message.
💡
Beginner tip
Think of @error as a hard fail for your Sass API—like throwing an exception in JavaScript. Fix the call site, then recompile.
Foundation
📝 Syntax
styles.scss
@mixin reflexive-position($property, $value) {
@if $property != left and $property != right {
@error "Property #{$property} must be either left or right.";
}
// … emit styles only when validation passes
}
Put the check near the top of the mixin or function. Fail fast before you compute or emit anything based on bad input.
Output
📤 Messages & Stack Traces
Official docs: the exact format of the error and stack trace varies by implementation and can also depend on your build system. In Dart Sass from the command line, you typically see the message, a caret pointing at the failing line, and frames for the mixin/function and the root stylesheet.
styles.scss
Error: "Property top must be either left or right."
╷
3 │ @error "Property #{$property} must be either left or right.";
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
╵
example.scss 3:5 reflexive-position()
example.scss 19:3 root stylesheet
💡
Write helpful messages
Say what was wrong, what was received, and what is allowed. Prefer "Got top; expected left or right." over a vague "Invalid argument."
Compare
⚖️ @error vs @warn vs @debug
At-rule
Stops compile?
Best for
@error
Yes
Invalid API usage; must not continue
@warn
No
Deprecations, soft guidance
@debug
No
Inspecting values while developing
Use @error when continuing would silently produce wrong or incomplete CSS. Use @warn when you want to nudge callers without breaking the build.
Patterns
🛡️ Common Validation Patterns
Allowed keywords — only left / right, or a fixed map of modes.
Types — meta.type-of($value) == number (or color, list, …).
Units — math.unit($x) or math.is-unitless($x).
Ranges — reject negatives or values outside 0–100.
Required config — fail if a map key or module variable is missing.
styles.scss
@use "sass:meta";
@function assert-number($value, $name: "value") {
@if meta.type-of($value) != number {
@error "#{$name} must be a number; got #{meta.type-of($value)} (#{$value}).";
}
@return $value;
}
Cheat Sheet
⚡ Quick Reference
Goal
Code
Hard fail
@error "Message here.";
Include a value
@error "Got #{$value}.";
Guard keywords
@if $x != left and $x != right { @error …; }
Guard type
@if meta.type-of($v) != number { @error …; }
Soft notice
Use @warn instead
Inspect a value
Use @debug instead
Hands-On
Examples Gallery
Valid calls show compiled CSS. Invalid calls show the compiler error (no CSS is produced). Open the output buttons to compare both paths.
📚 Getting Started
Guard mixin arguments with a clear hard fail.
Example 1 — Valid Mixin Call
When arguments pass the guard, styles compile normally.
styles.scss
@mixin reflexive-position($property, $value) {
@if $property != left and $property != right {
@error "Property #{$property} must be either left or right.";
}
$left-value: if($property == right, initial, $value);
$right-value: if($property == right, $value, initial);
left: $left-value;
right: $right-value;
[dir=rtl] & {
left: $right-value;
right: $left-value;
}
}
.sidebar {
@include reflexive-position(left, 12px);
}
left is allowed, so @error never runs and the mixin emits LTR/RTL positioning.
Example 2 — Invalid Mixin Call
Passing top triggers @error and stops the compile.
styles.scss
@mixin reflexive-position($property, $value) {
@if $property != left and $property != right {
@error "Property #{$property} must be either left or right.";
}
$left-value: if($property == right, initial, $value);
$right-value: if($property == right, $value, initial);
left: $left-value;
right: $right-value;
}
.sidebar {
@include reflexive-position(top, 12px);
// Error: Property top must be either left or right.
}
⚠️ Compiler error (no CSS produced):
Error: "Property top must be either left or right."
╷
3 │ @error "Property #{$property} must be either left or right.";
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
╵
error-invalid.scss 3:5 reflexive-position()
error-invalid.scss 14:3 root stylesheet
How It Works
The guard rejects top. Sass prints the message and stack, then aborts—so you fix the include instead of shipping broken layout CSS.
📈 Types, Failures & Ranges
Reusable assert helpers for functions.
Example 3 — Type Guard (Valid)
Assert a number, then use it in a calculation.
styles.scss
@use "sass:meta";
@use "sass:math";
@function assert-number($value, $name: "value") {
@if meta.type-of($value) != number {
@error "#{$name} must be a number; got #{meta.type-of($value)} (#{$value}).";
}
@return $value;
}
.card {
opacity: math.div(assert-number(80, "$opacity"), 100);
}
📤 Compiled CSS:
.card {
opacity: 0.8;
}
How It Works
80 is a number, so the assert returns it and math.div produces 0.8.
Example 4 — Type Guard (Invalid)
A string fails the same assert with a detailed message.
styles.scss
@use "sass:meta";
@function assert-number($value, $name: "value") {
@if meta.type-of($value) != number {
@error "#{$name} must be a number; got #{meta.type-of($value)} (#{$value}).";
}
@return $value;
}
.card {
opacity: assert-number("eighty", "$opacity");
}
⚠️ Compiler error (no CSS produced):
Error: "$opacity must be a number; got string (eighty)."
╷
11 │ opacity: assert-number("eighty", "$opacity");
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
╵
error-type-fail.scss 11:12 root stylesheet
How It Works
Reporting both the type (string) and the value (eighty) makes the fix obvious at the call site.
Example 5 — Unit & Range Checks
Accept unitless or % amounts only within 0–100.
styles.scss
@use "sass:math";
@use "sass:meta";
@function clamp-percent($amount) {
@if meta.type-of($amount) != number {
@error "$amount must be a number.";
}
@if not math.is-unitless($amount) and math.unit($amount) != "%" {
@error "$amount must be unitless or %; got #{$amount}.";
}
@if $amount < 0 or $amount > 100 {
@error "$amount must be between 0 and 100; got #{$amount}.";
}
@return $amount;
}
.badge {
--tint: #{clamp-percent(40%)};
width: clamp-percent(50) * 1%;
}
📤 Compiled CSS:
.badge {
--tint: 40%;
width: 50%;
}
How It Works
Both calls pass. Values like 120, -5%, or 10px would hit @error instead of emitting nonsense CSS.
Applications
🚀 Real-World Use Cases
Design-system APIs — reject unknown button sizes or themes.
Shared helpers — assert numbers before math.div.
Config modules — fail if required map keys are missing after @use … with.
Breaking changes — hard-fail removed options instead of ignoring them.
Teaching / code reviews — make incorrect includes fail loudly in CI.
🧠 How Compilation Works
1
Call a mixin/function
Your stylesheet includes or invokes an API with arguments.
Source
2
Run validation
Guards check types, keywords, units, or ranges.
Check
3
Hit @error (if invalid)
Sass prints the message and stack trace.
Fail
4
✓
Build stops
No CSS ships until the call site is fixed.
Watch Out
⚠️ Common Pitfalls
Vague messages — always include the bad value and allowed options.
Using @error for soft advice — prefer @warn for deprecations.
Validating too late — check arguments before emitting styles.
Forgetting interpolation — @error $value may print awkwardly; prefer a clear string with #{$value}.
Over-guarding private helpers — focus errors on public API surfaces.
Pro Tips
💡 Best Practices
✅ Do
Fail fast at the top of public mixins/functions
Name the argument in the message ($opacity)
Share small assert helpers across your library
Use meta.type-of and sass:math for precise checks
Let CI surface @error failures early
❌ Don’t
Swallow bad input and emit fallback CSS silently
Write @error "Error" with no context
Replace every @warn with a hard fail
Rely on browsers to catch Sass API mistakes
Validate deep private internals instead of the public call
Summary
Key Takeaways
Knowledge Unlocked
Five things to remember about Sass @error
Hard-fail bad API usage with a clear message and stack trace.
5
Core concepts
📝01
Stop
@error message
Fail
🔒02
Guard
args & types
API
📤03
Explain
got vs expected
Message
📈04
Trace
call stack
Debug
✓05
Choose
error ≠ warn
Hard
❓ Frequently Asked Questions
It prints the value of an expression (usually a string) plus a stack trace, then stops compiling the stylesheet and reports a failure to your build tool.
Use it in mixins and functions to enforce your API: wrong types, out-of-range values, unsupported keywords, or missing required configuration.
@error stops compilation. @warn prints a warning and continues. Use @warn for soft deprecations; use @error when continuing would produce broken CSS.
No. If @error runs, no finished CSS is produced for that compile. Browsers never see @error.
Yes. Interpolate with #{$name} so callers see the bad value, for example @error "Got #{$property}, expected left or right."
Implementations vary. Dart Sass typically shows the failing call site and how you reached the mixin or function. Exact formatting depends on your Sass version and build system.
Did you know?
Official Sass docs highlight @error specifically for mixins and functions that take arguments—so library authors can enforce contracts the same way typed languages enforce function signatures.
@error is your hard stop for invalid Sass API usage. Write clear messages, validate early in mixins and functions, and reserve @warn for softer guidance. A failing compile in CI is far better than silent bad CSS in production.