Zitat von
negaH:
2.) wir schauen in die Geschichte der Computerei, und stellen fest das sich eben fast NIE das durchgesetzt hat was das Beste darstellte. Es setzte sich immer das durch was im allgmeinen Interesse rundum praktisch war. Also das was sich auch gut vermarkten lässt, was Profit bringen wird und denoch technisch einigermaßen gelungen war. Also nicht das was hypothetisch supergut war aber zb. keinerlei Lobby dahinter hatte.
Ich habe die gleiche Beobachtung gemacht, aber andere Schlüsse gezogen. So denke ich bspw., daß es vielmehr so ist, daß viele Firmen nur kurzfristig orientieren. So ist das aktuelle Projekt wichtiger (und das rechnet man ja gegenüber einem Kunden ab) als die Zukunftsorientiertheit.
Beispiel: In der Firma, auf die ich anspiele, werden 2 Systeme eingesetzt um die Oberfläche für Kontrollstationen in Fabriken zu designen. Nun ist es so, daß ich mich krampfhaft an dem Design der einen (in der Firma beliebteren) Software orientieren mußte und deshalb in zahlreiche Schwierigkeiten kam. Stattdessen wäre es möglich gewesen eine Bibliothek aus für beide Systeme einheitlichen
ActiveX-Controls zu erstellen, die dann für ein einheitliches Aussehen und "corporate identity" gesorgt hätten. Das ist ist aber unbeliebt, weil man es nicht direkt an den Kunden weitergeben kann (bzw. dann bei einer Ausschreibung schlechter dasteht).
Zitat von
negaH:
Exception ansich sind ein sehr wichtiges Mittel der Programmierung geworden. Sie stellen sozusagen einen parallel zum eigentliche Programablauf feststehenden Programmablaufplan dar. Und exakt in dieser Parallelität sehe ich auch gleichzeitig die Schwäche der Exceptions. Denn im Denkvermögen der meisten Programmierer stellt sich ein Program am einfachsten als simple und rein sequientielle Steuerung dar.
Da stimme ich dir zu, allerdings muß dann IMO der Programmierer sich weiterbilden. So einfach ist das. Beispiel: in den heutigen SMP- und HT-Systemen (oder sogar kombiniert, oder Dual-Core usw.) muß ich auch auf die Parallelisierung achten. Mache ich das nicht, habe ich den falschen Job. Und da meine ich noch nichtmal parallele Ausführbarkeit, sondern einfach nur drauf achten, daß prinzipiell der Code mal auf der einen und mal auf der anderen CPU laufen kann. Bei Treibern muß ich das auch beachten.
Zitat von
negaH:
1.) wenn
Exception dann aber auch immer try finally benutzen um resourcen zu schützen, das verringert die Anzahl unerwünschter Nachfolgefehler falls eine
Exception/Event asynchron den Programfluß unterbricht.
Volle Zustimmung! (Einschränkung: dies ist bei Delphi so, siehe ganz unten)
Zitat von
negaH:
2.) Wissen, die Programmierer habe zu lernen wie asynchrone Programme per Exceptions/Events zu arbeiten haben
150%ige Zustimmung!
Zitat von
negaH:
3.) Beschränkungen, durch willkürlich Beschränkungen auf gemeinsam benutzte und Firmeninterene Vorgaben im Arbeitsstil.
... siehe oben. Sehe ich skeptisch, wenn auch eine gemeinsame Grundlage unabdingbar ist. Wenn es aber der kleinste gemeinsame Nenner (i.e. der döfste Programmierer im Team) ist, dann ist es schlecht.
Zitat von
negaH:
4.) das Eintreffen/Auslösen solche asynchrone Exceptions/Events möglichst reduzieren.
Bei der
RTL kann ich auch mitgehen.
Zitat von
negaH:
Nichts ist schlimmer wenn eine solche Funktion tief im Inneren eines Programmes ständig Exceptions auslösst.
Dann ist aber Punkt 2 wieder gefragt. Denn Exceptions heißen ja nicht umsonst Exceptions (also Ausnahmen).
Zitat von
negaH:
Nun führen wir aber in diese Funktion in deren Implementation eine
Exception ein. Wird diese ausgelösst so zerstört sie das Black-Box-Prinzip denn WIR SEHEN diese
Exception NICHT in der Schnittstelle !!??
Dies wäre ja eine Vermischung von
OOP und PP - ergo inkonsequent. Deswegen hast du recht, es ist nicht praktikabel.
Zitat von
negaH:
Exception sind also einerseits ein produktives Mittel aber andererseits ein möglicherweise kontrapoduktives Design da sie aus Sicht der Schnittstelle nicht sichtbar sind.
Bei Klassen sind sie dies aber (oder zumindest dokumentiert). Daher Exceptions bei
OOP, ansonsten nur die Exceptions (aka SEH) vom
OS (
AV oder ähnliches). Beide sind verschiedene Konzepte.
Zitat von
negaH:
[...] oder aber der Programmiere beginnt wild umsich zu try except'en und zerstört somit im Grunde den Nutzen der Exceptions.
Aber es reicht doch an sich für den Programmierer die Erkenntnis, daß er eine
Exception nicht am Ort des Auftretens behandeln muß - ergo muß er auch nicht "try except'en" und das Problem ist gelöst. Einfach die
Exception durchschlagen lassen bis zum letzten eigenen Handler (notfalls zum
OS). Wozu ist es zB gut eine
Exception, welche ausgelöst wurde, weil eine unbedingt nötige Ressource nicht geholt werden konnte, an Ort und Stelle behandelt wird? Eben, garnichts! Einfach durchschlagen lassen.
Der letzte fängt die
Exception 
Zitat von
negaH:
Das sind die Folgen eines schlechten Designes, und die Ursache liegt darin begründet das wir in der Schnittstelle unserer Funktionen/Merthoden etc. pp. eben nicht SEHEN welche
Exception zu erwarten sind.
Dazu gibt es Code-Dokumentationen
... und wenn wir uns mal angucken, daß Objekte eigentlich erstellt werden um wieder
benutzt zu werden, dann muß dem
Benutzer auch eine Doku vorliegen.
Um es auf einen Punkt zu bringen
Für mich gehören try-except-Blöcke in die
OOP-Welt und try-finally-Blöcke in die PP-Welt. Daß sie bei Delphi vermischt auftreten, haben wir der Tatsache zu verdanken, daß sie Objekte in Delphi nicht wie Stackvariablen verhalten (man sie also explizit freigeben muß, was oft in try-finally-Blöcken geschieht). Nichts dagegen, daß dies überhaupt möglich ist (auch in C++ kann ich über Objektzeiger gehen), aber in Delphi gibt es eben nur diese eine Möglichkeit. Ich gehe aber davon aus, daß Delphi.NET dafür eine Antwort hat. Robert_G? Anwesend? Sag mal was
Korrektur: Natürlich geht es auch in Delphi (nämlich mit Interfaces), aber eben nur über Umwege. Und wenn jetzt irgendjemand kommt und das unsägliche
object vorschlägt, dann bin ich aber raus aus der Diskussion. Das existiert bekanntlich nur für die Kompatibilität mit älteren Quelltexten.
EDIT2: jbg's Einwand eingearbeitet.