Fehlerhandling und Übersetzung

KK27

Hallo zusammen,

ich möchte meinen Horizont beim Thema Fehlerhandling und Übersetzungen im Bezug auf Exceptions erweitern.

Auf der Arbeit ist folgende Situation:
Wir haben kein „modernes“ Fehlerhandlingsystem. Übersetzungen werden über Makros/Defines gelöst. Für jede Fehlerklasse, die von einer Basisklasse abgeleitet ist, existieren #define-Konstanten für Fehlercodes sowie (falls nötig) eine eigene Übersetzungs-ID.

Was ich privat lernen/umsetzen möchte:
Ich schreibe privat kleine Projekte und möchte dort ein gutes, zeitgemäßes Fehlerhandling etablieren – idealerweise so, dass es sowohl für Logging als auch für Benutzertexte geeignet ist. Ich möchte auch mir eigene kleine Libs schreiben und dort möchte ich dann ein gutes Fehlerhandling System implementieren.

Beispiel:
Angenommen es gibt eine Domänenklasse Order. Der Konstruktor wirft bei ungültigen Parametern std::invalid_argument.

class Order {
public:
    Order(std::string id, int quantity) {
        if (id.empty()) {
            throw std::invalid_argument("Order id must not be empty"); 
        }
        if (quantity <= 0) {
            throw std::invalid_argument("Quantity must be positive");
        }
        // ...
    }
};

Fragen:

Sprache der Exception-Message:
Sollte die Nachricht in Exceptions standardmäßig Englisch/deutsch sein (neutral für uns Entwickler oder das Logging), oder sollte sie lokalisiert sein (z. B. Deutsch/Englisch/Spanisch je nach Umgebung)?
Mein Gedanke: Die Klasse könnte tief im Code oder nahe an der UI verwendet werden. An der UI ist Lokalisierung sinnvoll; tief im Code evtl. eher neutrale/englische Texte fürs Logging oder für die Entwicklung.
Mehrere mögliche Fehlerquellen in einem try/catch:
Wenn in einem Block mehrere Objekte std::invalid_argument werfen könnten:
Fangt ihr eher basistypisch catch (const std::exception& ex) und mappt dann zentral anhand von Fehlercodes?
Oder nutzt ihr für die Domäne eigene Exceptiontypen (z. B. OrderError, CustomerError), um präziser unterscheiden zu können?
Im Domain-Driven Design gäbe es ggf. eine UI Order Klasse, die den Auftrag in der UI darstellt. Wäre dann diese für das Mapping in die richtige Lokalisierung zuständig und nicht die normale Domain Klasse?
Trennt ihr Log-Text (stabil, englisch, mit technischen Details) von Benutzertext (lokalisiert, freundlich, kontextualisiert)? Wenn ja: Wie sorgt ihr dafür, dass beide Pfade konsistent bleiben?

Ich habe hier im Forums dazu nichts gefunden.