Nachdem MSElang "dein Baby" ist, kannst du natürlich tun, was dir am besten gefällt.
Denke aber deine Argumentation noch einmal in Ruhe durch:
mse hat geschrieben:Ums "create()" kommt man nicht herum, da so bestimmt wird, dass die Instanz im heap alloziert wird
raise ist ein eigenes Sprachkonstrukt speziell für das Exception-Handling. Was spricht dagegen, dass raise automatisch ein geeignetes Objekt am Heap alloziert? Wie du richtig schreibst, führt ohnedies kein Weg daran vorbei, das muss daher nicht explizit im Programm stehen. Und für den Programmierer ist völlig egal, wo genau dieses Objekt sitzt, ob im Heap oder sonstwo. Die Compiler Magic kümmert sich ja sogar um die korrekte Freigabe des Objekts, während bei "normalen" Heap-Objekten der Programmierer verantwortlich ist.
Und mir fällt, außer der Zuweisung von Parametern an lokale Felder, überhaupt nichts sinnvolles ein, was man im Create einer Exception machen könnte.
Ich versuche so wenig verschiedene Programmkonstrukte wie möglich einzuführen, daher das "except" Attribut in einer normalen Klasse statt eines speziellen "exception" Typ.
Im Prinzip ist der Ansatz für mich nachvollziehbar. Aber die Behandlung von Exceptions IST etwas völlig anderes als alles, was irgend eine "normale" Klasse leistet, und es gibt mit raise und try-except schon zwei dedizierte Sprachkonstrukte, die nur dafür zuständig sind. Da kommt es auf einen separaten, von normalen Klassen abweichenden Datentyp (der nebenbei die ganze Schreibweise wesentlich vereinfachen würde), wirklich auch nicht mehr an, insbesondere, weil für diesen Typ von den vielen anderen Features, die Klassen bieten, gar keine gebraucht werden.
mse hat geschrieben:Wenn man keine Nutzlast benötigt, kann man im "except"-Teil aufgrund des Object-Typ verzweigen. Da lediglich pointer verglichen werden, ist die performance optimal.
Wenn man anständigen Code schreibt, dann ist eine Exception immer die seltene Ausnahme, für den Fall, dass etwas schiefgelaufen ist, was eigentlich nicht passieren dürfte und der Programmierer nicht wirklich vorgesehen hat, meistens ein Fehler in einem anderen Programmmodul, der sich an dieser Stelle auswirkt. "Normale" Fehlerbedingungen sollte man m.E. vorher abfragen und nicht über ein try-Except abfangen. Deshalb hat die Performance gerade des raise-Statements und des except-Blocks keine Relevanz. Auch wenn das etwas langsamer ist, sollte das auf ein ordentlich designtes Programm unter normalen Umständen überhaupt keinen Einfluss haben, weil der Block im Normalfall gar nicht zur Ausführung kommen dürfte.
Gegen einen festen Klassentyp als Exceptionobjekt wie von dir vorgeschlagen sträubt sich in mir alles.
Ich würde diesen Exception-Typ gar nicht als (festen) Klassentyp bezeichnen, sondern als eigenen Typ, der nur in Verbindung mit raise und try-except zu verwenden ist, während normale Klassen an der Stelle gar nichts verloren haben. Wie ich oben geschrtieben habe, sind raise und try-except dedizierte Sprachkonstrukte nur für das Exception-Handling, denen kann man dann schon auch einen eigenen, für die Aufgabe besser geeigneten Datentyp gönnen
Ob der Datentyp intern als Klassentyp implementiert ist, kann dem Programmierer egal sein.