Sass @error Rule

Beginner
⏱️ 11 min read
📚 Updated: Jul 2026
🎯 5 Examples
Validate · stop compile

What You’ll Learn

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

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.

  • Best used inside mixins and functions.
  • 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.

📝 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.

📤 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."

⚖️ @error vs @warn vs @debug

At-ruleStops compile?Best for
@errorYesInvalid API usage; must not continue
@warnNoDeprecations, soft guidance
@debugNoInspecting 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.

🛡️ Common Validation Patterns

  • Allowed keywords — only left / right, or a fixed map of modes.
  • Typesmeta.type-of($value) == number (or color, list, …).
  • Unitsmath.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;
}

⚡ Quick Reference

GoalCode
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 noticeUse @warn instead
Inspect a valueUse @debug instead

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);
}

How It Works

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.
}

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);
}

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");
}

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%;
}

How It Works

Both calls pass. Values like 120, -5%, or 10px would hit @error instead of emitting nonsense CSS.

🚀 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.

⚠️ 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.

💡 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

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
🔒 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.

Conclusion

@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.

Continue with @warn or @mixin / @include.

Next: Sass @warn

Print soft warnings for deprecations and tips without stopping the compile.

@warn rule →

About the author

Mari Selvan M P
Mari Selvan M P 🔗

Developer, cloud engineer, and technical writer

  • Experience 12 years building web and cloud systems
  • Focus Full Stack Development, AWS, and Developer Education

I write practical tutorials so students and working developers can learn by doing—from databases and APIs to deployment on AWS.

5 people found this page helpful