# Diagnostics and Fallback

エラーは runtime value ではなく diagnostic として扱う。
処理系はエラー内容に基づく汎用的な実行時分岐を提供しない。

## Diagnostic

```text
Diagnostic {
  kind: DiagnosticKind
  span: Span
  message: String
  notes: Vec<Note>
}
```

代表的な diagnostic kind:

- syntax error
- unresolved identifier
- type mismatch
- constraint violation
- composition conflict
- default conflict
- cycle dependency
- import failure
- match failure
- materialization failure

## エラーは値ではない

評価失敗は `RuntimeValue` ではなく `Diagnostic` を返す。
そのため、通常の式はエラー内容に基づいて分岐できない。

```text
Result<RuntimeValue, Diagnostic>
```

これにより、制約違反、未定義識別子、循環依存、import 失敗などが通常値として流れることを避ける。

## `try / catch` は core に入れない

汎用 `try / catch` は core に入れない。
エラーを制御フローとして扱うと、どの失敗を捕捉できるか、捕捉後の thunk state をどう扱うか、制約違反を握りつぶしてよいか、といった仕様が重くなる。

fallback は有限で明示的な仕組みに限定する。

- `default`: 未指定値の fallback。
- `match`: 有限 pattern に基づく分岐。
- optional import: ファイル不存在など、限定された失敗だけを fallback 可能にする候補。
- optional field access: field 不在だけを fallback 可能にする候補。
- union / tagged schema: 複数 schema の選択を明示的に表す将来候補。

## optional fallback の扱い

optional import や optional field access を導入する場合も、捕捉できる失敗は限定する。

例として optional import は、ファイル不存在だけを fallback 可能にし、parse error や import 先の制約違反は diagnostic として報告する方がよい。

```text
optional import:
  file not found -> fallback
  parse error    -> diagnostic
  eval error     -> diagnostic
```

この方針により、fallback は通常の値選択として扱い、エラー内容に依存した実行時分岐は避ける。