# Error Handling Instructions

Aktualisiert: 2025-10-20

## Aktueller Zustand
- Fehler werden in Managern primär über `LOGGER.error(e)` geloggt.
- Rückgabe bool (true/false) signalisiert Erfolg/Misserfolg.
- Keine differenzierte Fehlerklassifikation (Business vs. System).

## Ziele
- Konsistente Behandlung & klare Trennung der Fehlerarten.
- Verbesserte Diagnose für Nutzer & Logs.

## Kategorien
1. Validation Errors (Bean Validation zukünftig) -> Nutzerfeedback.
2. Business Rule Violations -> eigene Exception (z.B. `BusinessException`).
3. System Errors (DB Down, Hibernate Exceptions) -> Logging + generische Fehlermeldung.

## Kurzfristige Empfehlungen
- Bei allen catch-Blöcken: `LOGGER.error("<Kontext>", e)` statt nur `LOGGER.error(e)`.
- Controller: Nach boolean false -> `errorMessage()` anzeigen.

## Einführung BusinessException (geplant)
- Checked oder Runtime? Vorschlag: Runtime zur vereinfachten Nutzung.
- Manager Methoden können `throw new BusinessException("Message")` statt false.
- Controller fängt BusinessException und zeigt spezifische Nachricht.

## Log Format
- Kontext + Entity-ID + Operation.
  Beispiel: `LOGGER.error("Failed to persist SecurityArea id={} name={}", area.getId(), area.getName(), e);`

## Edge Cases
- Null Übergaben -> früh validieren & BusinessException werfen (später) / false zurückgeben (jetzt).
- Sammeloperation: Teilfehler -> aktuell Abort bei erstem Fehler. Optional Sammeln & Aggregatfehler.

## Verbesserungen
- Central Exception Mapper (JSF PhaseListener / CDI Interceptor).
- Korrelation IDs in Logs (Request ID, User ID).

## Generator Leitplanken
- Logging immer, auch bei ignorable Exceptions.
- Keine System.out Nutzung.
- Fehler nicht stillschweigend verschlucken (mindestens loggen).

---