Articles
SASS/SCSS入門
SASS におけるエラー処理

SASS におけるエラー処理

この記事ではSASS におけるエラー処理について説明します。

SASSが提供するエラーや警告、デバッグの仕組みを使い、壊れにくいスタイル設計を実現する方法を解説します。

YouTube Video

SASS におけるエラー処理

SASS における「エラー処理」とは何か

SASS は実行時の例外を扱う言語ではありませんが、コンパイル時に不正な状態を検出し、開発者に明確に通知する仕組みを備えています。これにより、誤った値や設計ミスが 気づかれないまま CSS として出力されてしまう問題を防げます。

SASS におけるエラー処理は、「失敗したら止める」だけでなく、設計の前提条件をコードとして表現する手段でもあります。主に次の4つの方法が用意されています。

設計上許容できない状態を検出した場合に、コンパイルを即座に中断します。

問題があることを警告として通知しますが、コンパイル自体は継続されます。

変数や計算結果を出力し、値の流れや内部状態を確認するために使用します。

  • ガード条件（@if） 入力値や前提条件を事前に検証し、問題の発生を未然に防ぎます。

@error：致命的な誤りを確実に止める

@error は、設計上絶対に許容できない状態に使います。間違った値が渡された場合、即座にコンパイルを失敗させます。

1@mixin set-width($width) {
2  @if type-of($width) != number {
3    @error "Width must be a number.";
4  }
5
6  width: $width;
7}
  • このミックスインは、数値以外が渡された場合にビルドを止めます。意図しない使われ方を防ぐ「最後の防波堤」として非常に有効です。

単位チェックを含めた実践的な @error

数値であっても、単位が不正な場合は問題になります。SASS では unit() を使って単位を検証できます。

1@mixin set-padding($value) {
2  @if unit($value) != "px" {
3    @error "Padding must be specified in px.";
4  }
5
6  padding: $value;
7}
  • このようにすると、1rem や % を誤って渡した場合でも即座に検出できます。デザインルールをコードとして強制できる点が重要です。

@warn：非推奨や注意喚起に使う

@warn は、今すぐ壊れるわけではないが、望ましくない状態を知らせるために使います。CSS は生成されるため、段階的な移行に向いています。

1@mixin legacy-color($color) {
2  @warn "legacy-color is deprecated. Use theme-color instead.";
3
4  color: $color;
5}
  • このミックスインは警告を出しつつ、既存コードを壊しません。大規模プロジェクトでのリファクタリング時に特に有効です。

条件付きで警告を出すパターン

値の範囲チェックと組み合わせると、より実践的になります。

1@mixin set-opacity($value) {
2  @if $value < 0 or $value > 1 {
3    @warn "Opacity should be between 0 and 1.";
4  }
5
6  opacity: $value;
7}
  • 設計ミスを知らせつつ、開発を止めない判断ができます。「厳しさのレベル」を選べるのが @warn の強みです。

@debug：値の流れを可視化する

@debug はエラー処理というより、問題を特定するための観測手段です。計算結果や変数の中身を確認できます。

1$base-size: 8px;
2$spacing: $base-size * 3;
3
4@debug $spacing;
  • コンパイル時に値が出力されるため、複雑な計算ロジックの検証に役立ちます。本番コードには残さず、調査用途に限定しましょう。

@if を使ったガード設計が最重要

実務では、@error や @warn の前段階として、入力を検証する設計が最も重要です。

1@mixin grid-columns($count) {
2  @if type-of($count) != number or $count <= 0 {
3    @error "Column count must be a positive number.";
4  }
5
6  grid-template-columns: repeat($count, 1fr);
7}
  • このように「正しい前提条件」を明示すると、ミックスインや関数が自己説明的になります。

関数（@function）でのエラー処理

関数でも同様にエラー処理が可能です。特に計算ロジックでは重要になります。

1@function divide($a, $b) {
2  @if $b == 0 {
3    @error "Division by zero is not allowed.";
4  }
5
6  @return $a / $b;
7}
  • CSS 生成前にロジックの破綻を検出できるため、デザインシステムの安全性が向上します。

実務での使い分け指針

最後に、実務で判断に迷いやすいポイントを踏まえて、使い分けの基準を整理します。

  • 設計違反やバグが明確に確定している場合 @error を使用します。誤った状態のまま CSS を生成すると不具合に直結するため、コンパイルを即座に停止させます。

  • 非推奨であることを伝えたい場合や注意喚起にとどめたい場合 @warn を使用します。将来的な問題を知らせつつ、既存コードや移行中の実装を壊さずに運用できます。

  • 値の流れや計算結果を確認したい場合 @debug を使用します。ロジックの検証や原因調査を行うための、一時的な手段として有効です。

  • 入力値や利用条件など、すべての前提条件を検証したい場合 @if によるガードを使用します。前提を明示することで、問題が発生する前に未然に防ぐことができます。

SASS は「書けてしまう」言語だからこそ、書いてはいけない状態をコードとして明確に定義する設計が、長期的に保守しやすく、破綻しにくいスタイル設計につながります。

まとめ

SASS におけるエラー処理は、スタイル設計の前提やルールをコードとして明示し、守り続けるための仕組みです。

  • エラーは、不正な状態を見逃さず、その場で確実に止めるために存在します。
  • 警告は、今すぐ壊さずに、将来の変更や移行を安全に進めるための道しるべです。
  • ガードは、問題が起きてから対処するのではなく、起きないように設計するためのものです。

これらを意識して使い分けることで、SASS は単なる CSS の拡張にとどまらず、意図と制約を表現できる、信頼性の高い設計言語として機能するようになります。

YouTubeチャンネルでは、Visual Studio Codeを用いて上記の記事を見ながら確認できます。 ぜひYouTubeチャンネルもご覧ください。

YouTube Video

SASS と BEM