Zitat von
jbg:
Du meinst wohl object. TObject ist bei Delphi eine class.
Ja, tue ich. Danke für den Hinweis.
Zitat von
jbg:
Um auf das angeben von Exceptions im Interface zu kommen. Java hat dies in die Syntax eingebaut: "void bla() throws MyException".
C++ ebenfalls. Man sieht die Wurzeln von Java
Zitat von
jbg:
as macht meines erachtens aber nur solange Sinn, wie man die Exceptions direkt vor Ort behandelt. Denn wenn man die nun durchzuschleifen probiert, hat man das Problem, dass man bei allen Methoden das throws anpassen muss
Bei neueren C++-Compilern dient das Attribut nur als "Dokumentationshilfe".
Zitat von
jbg:
was bei größeren Projekten (mit einer kleinen Änderung im Kern: neue
Exception) dann zu einer Sisyphusarbeit ausartet.
Ja, hast ja recht. Ich meine auch nicht, daß man jede
Exception durchschlagen lassen muß.
Nochmal mein Beispiel. Ich habe eine Molekülklasse geschrieben, die intern sog. Tripods ("Dreibeine") benutzt um 2 Atome und 3 Bindungen darzustellen. Nach außen ist das nicht sichtbar. Im Sinne der Effizienz ist es nun so, daß man von außen auf beliebige Bindungen oder Atome zugreifen kann (auch nichtexistente!). Intern ist es wie gesagt ein 2D-Array dieser Tripods. Ist der Zugriff nicht erfolgreich ("out of range") behandele ich die
Exception lokal und erweitere das Array und ggf. erstelle ich das vorher nicht vorhandene Tripod-Objekt. Hier werden Exceptions sehr sinnvoll eingesetzt und sind nach außen nicht sichtbar.
Zitat von
negaH:
es ist schwer eine solche Grundsatzdiskussion über das Netz zu führen. Lieber würde ich sowas in einer persönlichen Diskussion klären. Denn im Grunde vertreten wir ähnliche Ansichten, der Unterschied zwischen uns besteht nur darin aus welchem Winkel wir die Problematik betrachten und was für Schlüsse wir letzendlich daraus ziehen.
Kann sein. Wir kriegen das aber auch noch auf die Reihe (persönliche Diskussion)
Zitat von
negaH:
BEIDES ist aber kontraproduktiv, denn ein programmiertes Feature macht nur dann effektiv Sinn wenn es mir Arbeit abnimmt und einsparrt, und nicht zus. Zeit kostet weil es im Grunde in der Schnittstelle undokumentiert ist.
Stimmt!
Zitat von
negaH:
Und schwups sind wir bei der Dokumentation. Ein sauberer Source sollte komplett ohne Doku auskommen können
Du meinst ohne externe Dokumentation? Für mich gehen "externe" Dokumentation und Kommentare Hand in Hand, weil ich u.a. doxygen verwende.
Zitat von
negaH:
Denn in dieser Form der Sprache haben WIR die Regeln festgelegt und diese Regeln arbeiten immer nach dem Prinzip einer öffentlichen Schnittstellendeklaration und einer Black Box Implementation.
Aber genau deswegen muß doch eine Dokumentation existieren (sei es nun in Form von Kommentaren im Text oder extern).
Allein die Wahl eines Methodennamens muß ja nicht sonderlich clever sein. Wenn die Dokumentation existiert ist's aber kein Problem.
Zitat von
negaH:
Aus diesem Grunde geht der Vorteil der Schnittstelle und dem Black Box Prinzip kaputt denn der Entwickler muß nun doch wissen ob innerhalb der Black Box eine
Exception auftreten kann. Ergo: der Source muß dies separat dokumentieren, er wird also auf Grund seiner Schnittstellen Deklaration nicht mehr selbsterklärbar sein, und schwups wieder ein alter Vorteil verloren.
Ich verstehe was du meinst. Wo ist aber der Nachteil? Ob ich nun Fehlercodes dokumentiere oder Exceptions (die sogar noch komplexeres tun
können) ist doch einerlei.
Zitat von
negaH:
Ich möchte hier nicht gegen Exceptions argumentieren, sondern eher das dahinterliegende Konzept im Gesamtkonzept der Programmiermethoden analysieren. Und deshalb meinte ich eingangs das
Exception tatsächlich in jedlicher Weise eine Ausnahme darstellen. Der Grad ihrer Nützlichkeit ist also sehr schmal für uns Programmierer.
Das ist wohl wahr.