Zitat von
3_of_8:
Naja, stell dir folgendes vor:
Du hast eine Klasse TWuppdiLoader, die eine Datei vom Typ
Wuppdi Laden soll. In der Dateitypspezifikation steht eine CRC32-Prüfsumme. Die stimmt aber nicht mit der Datei überein. Was machst du da? Du könntest jetzt die Funktion beenden und einen Statuscode zurückgeben (z.B. ein Set mit den aufgetretenen Fehlern) oder ein Feld in der Klasse setzen. Aber was ist, wenn der Fehler in irgendeiner Funktion weit verschachtelt auftritt? Dann brauchst du nach jedem Funktionsaufruf sowas wie if FError then exit;
Da ist eine
Exception mehr als angemessen, ich würde sogar sagen, für gute Programmierung unausweichlich.
Was spricht aber in dem Fall dagegen ganz oben die
Exception abzufangen und in der obersten Funktion dann einen Fehlercode zurück zu geben. Auf diesen kann dann programmseitig auch noch eingegangen werden um ungültige eingaben nicht zu zulassen. Fände ich auf jeden fall besser als dem user die Exceptions um die Ohren zu werfen mit denen er am ende gar nichts anfangen kann.