Warum sind hier so wenig C# Programmierer? [was: Bla...]

dschensky

Optimizer schrieb:

Mich nervt aber, dass es keine const-correctness...gibt...

Vermutlich würden irgend welche Leute dann sofort nach const_cast schreien ...

Zumindest finde ich es schon bedenklich, dass eine Funktion nicht zusichern kann, ein übergebenes Objekt nicht zu verändern.

Shade Of Mine

Optimizer schrieb:

keine checked Exceptions

http://www.artima.com/intv/handcuffs.html

Bei dem const stimme ich dir aber zu.

Ich weiss, dass du checked Exceptions nicht magst. Aber ich mag sie. Weil ich sicher sein kann, dass mein Programm nicht abkackt. Ich finde es nicht zeitgemäß, selber schauen zu müssen, ob ich wirklich alle Exceptions abgefangen habe. Ich denke einfach nicht immer bei jeder Kleinigkeit daran (Programmsymbol aus Datei laden, whatever. Es gibt so viele kleine unwichtige Sachen, die man leicht vergisst). Manchmal ist es mir auch gar nicht möglich, das vorher zu wissen, siehe oben das DoEvents().
Ich habe bisher noch keine einleuchtenden Argumente gegen checked Exceptions gehört, aber ich setze mich gerne mit dem Artikel auseinander:

Let's say I create a method foo that declares it throws exceptions A, B, and C. In version two of foo, I want to add a bunch of features, and now foo might throw exception D. It is a breaking change for me to add D to the throws clause of that method, because existing caller of that method will almost certainly not handle that exception.

Adding a new exception to a throws clause in a new version breaks client code.

Ich betrachte die throws-Liste als Teil der Schnittstelle. Wenn ich die Schnittstelle ändere, breche ich mit Client Code, ist doch vollkommen klar. Was mir aber nicht klar ist, warum meine Methode, wenn ich etwas ändere, plötzlich eine völlig neue Exception werfen soll, die auch nicht von den bisherigen abgeleitet ist. Da muss schon auf einmal einiges anders laufen und dann kann sich auch die Schnittstelle ändern. Mir fällt dazu aber kein realistisches Szenario ein, so abstrakt mit "A, B, C" kann ich auch jederzeit was formulieren.
Last, but not least: wenn meine Methode auf einmal tatsächlich eine neue Exception vom Typ D wirft, brichst du bei unchecked mit Client Code genauso, weil der sich jetzt auch um die Exception kümmern muss/sollte, wenn sie nicht vom Compiler bemängelt wird. Der Unterschied: bei unchecked Exceptions kann ich es vergessen, diese Änderung vorzunehmen! Was für mich eindeutig ein Nachteil ist, wird hier als Vorteil dargestellt. Sehr unüberzeugend.

Genau auf meinen letzten Punkt wird kurz darauf nochmal eingegangen:

No, because in a lot of cases, people don't care. They're not going to handle any of these exceptions. There's a bottom level exception handler around their message loop. That handler is just going to bring up a dialog that says what went wrong and continue.

Aha. Und kann ich das mit checked Exceptions nicht mehr machen oder was?
Wenn ich eine neue Exception habe, ist die doch in der Regel von einer der alten oder von einer gemeinsamen Basisklasse abgeleitet. Wenn ich eine völlig unabhängige und völlige neue Exception habe, dann habe ich sowieso irgendwas an der Methode komplett geändert. Wenigstens vergesse ich dann bei checked Exceptions nicht, mich anzupassen.

You don't want a program where in 100 different places you handle exceptions and pop up error dialogs. What if you want to change the way you put up that dialog box? That's just terrible. The exception handling should be centralized, and you should just protect yourself as the exceptions propagate out to the handler.

Woher will der wissen, was ich will? Ich will Exceptions dort behandeln, wo es vom Kontext her Sinn macht und nicht alles in der MainLoop, wie hier beschrieben. In der MainLoop weiss ich auch nicht mehr, was es jetzt mit der KonnteDiesesEineByteNichtLesenException auf sich hat. Behandeln kann ich sie in der MainLoop nicht mehr, da hab ich jetzt viel davon, wenn ich noch einen dummen Fehler ausgebe, anstatt die Exception dort, wo es sinnvoll ist, zu behandeln.

In the small, checked exceptions are very enticing. With a little example, you can show that you've actually checked that you caught the FileNotFoundException, and isn't that great? Well, that's fine when you're just calling one API. The trouble begins when you start building big systems where you're talking to four or five different subsystems.

Nein. Wenn ich nicht genauer differenzieren will, kann ich auch meine 50 Operationen in einem try-Block machen und eine allgemeine IOException fangen. Setzt natürlich voraus, dass die Exception-Hierarchie sinnvoll aufgebaut ist.
Hier wird immer argumentiert, dass die Leute dann nur noch sagen "throws Exception", was halt einfach nicht stimmt. Ich kann so allgemein werden wie ich will und kein Stück mehr.

Ich möchte auch nochmal klarstellen, dass natürlich nicht jede einzelne Exception checked ist. Das wird ja hier ganz gekonnt verschwiegen. Natürlich wäre es Müll, wenn ich bei jeder Methode einen IndexOutOfBoundsException und eine NullPointerException fangen müsste.

meiner Meinung nach sind checked Exceptions eher für Anfänger die erinnert werden müsse das da was schief gehen kann. Wenn man ordentlich programmiert muss man sich im klaren sein, dass eine Methode jederzeit Exceptions werfen kann und in solchen Fällen muss der verantwortungsbewusste Programmierer darauf vorbereitet sein. Wenn der Compiler einen dies erst du eine Fehlermeldung klar machen muss finde ich das ziemlich traurig!

Grüße Dirk

Dirk04 schrieb:

meiner Meinung nach sind checked Exceptions eher für Anfänger die erinnert werden müsse das da was schief gehen kann. Wenn man ordentlich programmiert muss man sich im klaren sein, dass eine Methode jederzeit Exceptions werfen kann und in solchen Fällen muss der verantwortungsbewusste Programmierer darauf vorbereitet sein. Wenn der Compiler einen dies erst du eine Fehlermeldung klar machen muss finde ich das ziemlich traurig!

Grüße Dirk

So eine schachsinnige Aussage, ich könnte heulen!
Hast du schon mal ein Programm geschrieben, dass größer als 2000 Zeilen ist in einer Programmiersprache, wo ausgiebig mit Exceptions gearbeitet wird, auch in der Standardbibliothek, im Gegensatz zur STL.
Das hat mit "vergessen" gar nichts zu tun. Ich möchte nicht an so einen Dreck denken müssen und bin froh, wenn mir die Arbeit abgenommen wird.
Manche Exceptions sind einfach nur dafür da, um wirklich gefangen zu werden, weil es halt einfach unvermeidbar sein kann, dass sie ausgelöst wird (FileNotFoundException). Es ist doch richtig, dass ein Programm damit rechnen muss, eine Datei nicht zu finden.
Und warum sollte ich selber daran denken müssen, wenn ich das einen Compiler machen lassen kann, der sowieso den ganzen Tag nichts besseres zu tun hat? Es kann schließlich nicht angehen, dass ein Programm nicht angemessen auf sowas reagiert sondern plötzlich beim Endkunden in der Konsole eine Exception samt Stack Trace dasteht.

Optimizer schrieb:

So eine schachsinnige Aussage, ich könnte heulen!
Hast du schon mal ein Programm geschrieben, dass größer als 2000 Zeilen ist in einer Programmiersprache, wo ausgiebig mit Exceptions gearbeitet wird, auch in der Standardbibliothek, im Gegensatz zur STL.

ja, z.B. Java: gerade da ist es nervig z.B. bei jeder eingabe eine IOException zu fangen.

Optimizer schrieb:

Das hat mit "vergessen" gar nichts zu tun. Ich möchte nicht an so einen Dreck denken müssen und bin froh, wenn mir die Arbeit abgenommen wird.
Manche Exceptions sind einfach nur dafür da, um wirklich gefangen zu werden, weil es halt einfach unvermeidbar sein kann, dass sie ausgelöst wird (FileNotFoundException). Es ist doch richtig, dass ein Programm damit rechnen muss, eine Datei nicht zu finden.
Und warum sollte ich selber daran denken müssen, wenn ich das einen Compiler machen lassen kann, der sowieso den ganzen Tag nichts besseres zu tun hat? Es kann schließlich nicht angehen, dass ein Programm nicht angemessen auf sowas reagiert sondern plötzlich beim Endkunden in der Konsole eine Exception samt Stack Trace dasteht.

mal angenommen du Programmierst in einer größeren Firma, wo das compilen eines Programms z.B. über die Nacht dauert. Was machst du da? Da kannst nicht mal schnell compilen und überprüfen ob du irgentwo einen Syntax Fehler drinhast oder, wie zum Thema, du eine Exception nicht "auffängst". Also musst du schon wissen wo welche Exception geworfen wird und zusätzlich noch welche du auffangen musst -> dein Argument ist "fürn Arsch".

Dirk04 schrieb:

ja, z.B. Java: gerade da ist es nervig z.B. bei jeder eingabe eine IOException zu fangen.

So gehört es sich auch. Im Java API wird eben mit Exceptions gearbeitet und wenn eine Datei nicht findet, fliegt halt ne FileNotFoundException. Aber du kriegst ja eh schon alle möglichen Exceptions, wenn du IOException fängst. Was stört dich überhaupt daran? In C++ wird halt mit Rückgabewerten gearbeitet, in Java mit Exceptions. Dementsprechend unterstützt der Java Compiler diese Vorgehensweise und setzt durch, dass sie gefangen werden.
Du kannst ja das ganze Laden aus 9834579 Dateien in eine Methode schreiben und nur die Methode mit nem try-Block umgehen. Das ist doch das feine, du kannst genau dosieren wie es dir gefällt.

try
{
    load934865Files();
}
catch(IOException ex)
{
    System.err.println("Sorry, Fehler.");
    /* reagiere angemessen */
    // Das bekommt keiner zu sehen, aber im logfile stehen jetzt _sehr_ nützliche Informationen
    logfile.println(ex);
    ex.printStackTrace(logfile);
}

mal angenommen du Programmierst in einer größeren Firma, wo das compilen eines Programms z.B. über die Nacht dauert. Was machst du da? Da kannst nicht mal schnell compilen und überprüfen ob du irgentwo einen Syntax Fehler drinhast oder, wie zum Thema, du eine Exception nicht "auffängst". Also musst du schon wissen wo welche Exception geworfen wird und zusätzlich noch welche du auffangen musst -> dein Argument ist "fürn *****".

So ein Quatsch. Du kennst wohl Java nicht. Wenn ich es mal wo vergessen habe, kann die Änderung machen und diese eine Klasse neu compilieren.
Überhaupt ist das Blödsinn. Genauso wie ich schauen muss, dass die Methodenaufrufe bei Klassen, die von anderen geschrieben wurden, zusammenpassen, muss ich halt schaun, dass ich die Exceptionsignatur berücksichtige. Die ist halt Teil der Schnittstelle, mein Gott.
Ich kann halt nicht an ner Methode, die ein Complex als Parameter will, ein double übergeben. Es ist nun mal unvermeidlich, dass man auf die Schnittstelle gucken muss. Und wenn ich will, dass jemand meine Exception behandelt, verwende ich ebene eine checked Exception. Ist doch cool, dass das möglich ist. Und wenn ich es nicht will, verwende ich eine unchecked.

Optimizer schrieb:

mal angenommen du Programmierst in einer größeren Firma, wo das compilen eines Programms z.B. über die Nacht dauert. Was machst du da? Da kannst nicht mal schnell compilen und überprüfen ob du irgentwo einen Syntax Fehler drinhast oder, wie zum Thema, du eine Exception nicht "auffängst". Also musst du schon wissen wo welche Exception geworfen wird und zusätzlich noch welche du auffangen musst -> dein Argument ist "fürn *****".

So ein Quatsch. Du kennst wohl Java nicht. Wenn ich es mal wo vergessen habe, kann die Änderung machen und diese eine Klasse neu compilieren.

Ach nee
Wie kommst du überhaupt darauf das ich mich in der Annahme auf Java beziehe? Hier geht es ja darum, was wäre wenn C# checked Exceptions hätte und da kannst du nicht jede klasse einzeln übersetzen!

C# hat genauso ein fortschrittliches Übersetzungsmodell wie Java, nur dass dort "Assemblies" die kleinsten Einheiten sind.

C++ Forumbot

Dieser Thread wurde von Moderator/in CMatt aus dem Forum C# und .NET in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Dirk04 schrieb:

ja, z.B. Java: gerade da ist es nervig z.B. bei jeder eingabe eine IOException zu fangen.

Weil gerade bei jeder Dateioperation sowas auch schief gehen kann!

Was ist die alternative? Dateioperationen durchführen und jedesmal hoffen das
es gut geht?

Nein ich bin gottfroh das mir schon der Compiler sagt, hoppla bei dieser Operation könnte was schief gehen, wie ist dein Plan?
Ignorieren kann mann auch checked Exceptions.

try { gefahr(); } catch(Exception e) {}

Das dies nicht intelligent ist, sei mal dahingestellt.