rustkeep/.scratch/rustkeep-1.0/issues/04-fehlerstrategie.md

04 — Fehlerstrategie für kaputte Mods

Type: grilling Status: open Blocked by: 03

Question

Was passiert, wenn ein Mod kaputt ist — und wie sieht das im Rust-Code aus?

Explizites Rust-Lernticket. Heute macht items.rs::parse() ein panic! mit Backtrace; bei Mod-Support ist fehlerhaftes TOML der Normalfall, nicht der Ausnahmefall. Zu klären:

• Welche Fehlerklassen gibt es? TOML-Syntax kaputt, Pflichtfeld fehlt, unbekannte Typ-ID, Abhängigkeit nicht installiert, ID-Kollision ohne Override-Absicht.
• Welche davon sind hart (Start abbrechen) und welche weich (Mod überspringen, Rest laden, warnen)?
• Wie erreicht die Meldung den Spieler — vor dem TUI-Start auf stderr, oder als Bildschirm im TUI? Braucht es ein Mod-Log?
• Rust-seitig: eigener Fehlertyp mit thiserror, oder anyhow mit Kontext, oder handgeschriebenes enum LoadError? Wo endet die Result-Kette?
• Wie kommt die Herkunft in die Meldung — Datei, Zeile, Mod-ID?

Ergebnis: Fehlerklassifikation, Reaktion je Klasse, und die gewählte Rust-Fehlerbehandlung mit Begründung.

Vorgabe aus Ticket 03

Ticket 03 klassifiziert seine eigenen Fälle bereits durch: hart ist allein depends fehlend oder in der Reihenfolge verletzt, alles Übrige ist Warnung plus Überspringen. Fehlereinheit ist der einzelne Eintrag, nicht der Mod und nicht das Spiel.

Offen bleibt damit: kaputte TOML-Syntax (die Datei ist unlesbar, die Einheit „Eintrag" greift nicht), fehlende Pflichtfelder, unaufgelöste Referenzen aus Phase 3 — und wohin die Warnungen gehen, wenn der Bildschirm ratatui gehört. Ein Ladelauf produziert leicht ein Dutzend, und println! ist nach dem TUI-Start keine Option mehr.