35 lines
1.7 KiB
Markdown
35 lines
1.7 KiB
Markdown
# 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](03-mod-ladepipeline.md) 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.
|