エラーと検証#
エラーは、どの段階で問題が見つかったかによって対処が変わります。構文として読めること、型が合うこと、GPUで実行できることを分けて確認します。
| 段階 | 例 | 確認すること |
|---|---|---|
| 構文 | 括弧や;の不足、閉じていないコメント |
記法と診断の位置 |
| 名前 | 未定義の名前、重複した宣言 | 関数・入力・ローカルの所属 |
| 型 | Stringへの数値演算、Enumの不一致 | 入力の型と明示変換 |
| 接続・下書き | 必要な入力が未接続 | 選んだ出力に必要か、編集途中か |
| 実行 | 未対応GPU型、サイズやメモリの上限 | 実行プロファイルと具体的な理由 |
| ホスト・資源 | 入力画像が未取得、外部ファイルの問題 | AEの入力、時刻、資源の状態 |
典型的な修正#
1はFloatです。Integerの関数へ渡す場合には、literal(Integer, 1)などで型を明示します。Stringにはliteral(String, "...")を使い、連結にはstring_concatを使います。
!valueがエラーになる場合は、valueがBooleanかを確認します。数値のゼロ判定にはvalue == 0のような比較を書きます。Enumは選択肢の順序から別のEnumへ自動変換されません。
検証の範囲#
対話中は、現在の出力から必要な処理をたどって検証・実行します。未接続ノードや別関数の下書きは、それだけで現在の出力を壊してはいけません。無効な下書きも、検証済みの実行中プログラムを置き換えません。
ドキュメントのコード例の検証は、例に含まれるすべての関数を検査します。先頭の関数だけが正しくても合格にはしません。型を通しただけで、GPU・AE・性能の確認まで済んだとは扱いません。
転送や更新が間に合っていない状態と、意味的に実行不能な状態は区別します。Previewや情報ギズモは観察の画面であり、表示待ちを言語の型エラーとして扱いません。詳しくは評価とPreviewを参照してください。