Die Ausnahmebehandlung (EH) scheint der derzeitige Standard zu sein, und bei der Suche im Internet kann ich keine neuen Ideen oder Methoden finden, die versuchen, sie zu verbessern oder zu ersetzen (gut, es gibt einige Variationen, aber nichts Neues).
Auch wenn die meisten Menschen dies zu ignorieren oder einfach hinzunehmen scheinen, EH hat einige große Nachteile: Ausnahmen sind für den Code unsichtbar und es entstehen viele, viele mögliche Ausstiegspunkte. Joel auf Software schrieb eine Artikel darüber . Der Vergleich mit goto passt perfekt, es hat mich wieder zum Nachdenken über EH gebracht.
Ich versuche, EH zu vermeiden und nur Rückgabewerte, Rückrufe oder was auch immer für den Zweck geeignet ist, zu verwenden. Aber Wenn man zuverlässigen Code schreiben muss, kann man EH heutzutage einfach nicht mehr ignorieren. : Es beginnt mit dem new die eine Ausnahme auslösen kann, anstatt einfach 0 zurückzugeben (wie in den alten Tagen). Dies macht jede Zeile von C++-Code anfällig zu einer Ausnahme. Und dann gibt es noch mehr Stellen im C++-Grundlagencode, die Ausnahmen auslösen... std lib tut es, und so weiter.
Das fühlt sich an wie auf wackligen Beinen stehend .. Jetzt sind wir also gezwungen, uns um Ausnahmen zu kümmern!
Aber es ist schwer, wirklich schwer. Man muss lernen, ausnahmesicheren Code zu schreiben, und selbst wenn man schon etwas Erfahrung damit hat, muss man immer noch jede einzelne Codezeile doppelt überprüfen, um sicher zu sein! Oder man fängt an, überall try/catch-Blöcke einzubauen, was den Code unübersichtlich macht, bis er unlesbar wird.
EH ersetzte den alten sauberen deterministischen Ansatz (Rückgabewerte ), der nur ein paar wenige, aber verständliche und leicht lösbare Nachteile hatte, durch einen Ansatz, der viele mögliche Ausstiegspunkte in Ihrem Code schafft, und wenn Sie anfangen, Code zu schreiben, der Ausnahmen abfängt (was Sie gezwungen sind, irgendwann zu tun), dann schafft er sogar eine Vielzahl von Pfaden durch Ihren Code (Code in den Catch-Blöcken, denken Sie an ein Serverprogramm, wo Sie andere Protokollierungsmöglichkeiten als std::cerr benötigen ). EH hat Vorteile, aber das ist nicht der Punkt.
Meine eigentlichen Fragen:
- Schreiben Sie wirklich ausnahmesicheren Code?
- Sind Sie sicher, dass Ihr letzter "produktionsreifer" Code ausnahmesicher ist?
- Können Sie überhaupt sicher sein, dass es so ist?
- Kennen und/oder nutzen Sie Alternativen, die funktionieren?
