Files
pi_mcps/java/mss-failsafe/.github/error_handling.instructions.md
T
Patrick Plate 1a0a56a626 chore(java): consolidate mss-failsafe to single canonical copy
Replace the stale multi-module java/mss-failsafe skeleton (old user-management
prototype) with the active single-module machine-safety inspection app that was
living in its own standalone repo at the repo root.

- Remove old java/mss-failsafe/ multi-module tree (mss, userdata, userManagement,
  mssfailsafe.datalayer, mssfailsafeWeblayer) incl. committed build artifacts
- Add the active app (PrimeFaces 11 / JSF 2.3 / Hibernate 5.6 / iText / POI)
  flattened into java/mss-failsafe/ as the only mss-failsafe in git
- Working tree captured = master tip 2a142b5 + in-progress uncommitted work
  (incl. .github/*.instructions.md AI-context files)
- Archive the standalone repo's 33-commit history in GIT_HISTORY_ARCHIVE.md
  since its .git was not migrated

This is the source of truth / base for the upcoming upgraded rewrite.
2026-06-13 19:55:28 +02:00

1.8 KiB
Executable File

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).