nicht angemeldet
Tach!
Abkürzungen und Fachbegriffe sollte nochmal betrachtet werden, ob man da nicht noch anfängerfreundliche Kurzerklärungen/Übersetzungen hinzufügen kann. Ist ja nicht jedem geläufig, was zum Beispiel API heißt.
Werde ich auch nochmal im gesamten Artikel drauf achten. Ich hab schon versucht, bei möglichst allen Vorkommen von sowas auf das Glossar zu verlinken
Das ist mir beim weiternen Lesen dann auch aufgefallen. Und ich habe auch nicht mehr so darauf geachtet, mehr auf inhaltliche Dinge. Eigentlich fiel mir nur API als noch erklärwürdig auf. Das muss man am Ende nochmal prüfen, wenn der Inhalt erstmal so gut wie fertig ist. Glossar-Verlinkungen sind auch nicht verkehrt. Wenn es für das Verständnis wichtig ist, sollte man jedoch lieber ein paar Worte an Ort und Stelle fallenlassen. Aber wie gesagt, erstmal der Inhalt.
Die Schachtelung bei Fehleraufkommen müsste noch etwas sinnvoller gestaltet werden. Momentan ist das alles linear. Das lässt sich zwar besser unterbrechen, um Dinge zu erklären, aber im realen Leben kann man ja nicht (ungestraft) einfach weitermachen, wenn ein Verbindungsfehler oder einer bei einer vorhergehenden Funktion/Methode aufgetreten ist.
Hättest Du da einen Vorschlag? Ich wollte das halt so „offen“ wie möglich halten, da das ja tatsächlich davon abhängig ist, was man gerade vorhat. Sollte ich sonst evtl. weitere geplante Artikel hintenanstellen und erstmal ein Anfängertutorial mit ein paar konkreten Beispielen schreiben, auf das man dann verweisen kann? Ich denke, das könnte man in so einem Rahmen wahrscheinlich etwas besser erklären. Oder was meinst Du?
Da muss ich nochmal genauer überlegen. Einserseits kann man die Beispiele als zusammengestellte Code-Stücke betrachten, zwischen denen eigentlich noch anderer Code der Anwendung zu liegen kommt. Die Verbindung wird ja nicht für jedes Statement separat geöffnet (sollte sie jedenfalls nicht). Andererseits sollt man schon eine vollständige und sinnvolle Vorgehensweise zeigen. Das bläht sich dann ganz schnell auf, aber in der Praxis ist das ja nicht anders.
try-catch kann seinen Vorteil auch viel besser ausspielen, wenn nicht jeder Fehler einzeln gefangen und behandelt wird, sondern wenn diese Behandlung am Ende steht.
Ja, so verwende ich try-catch auch üblicherweise. Hier hatte ich auch tatsächlich zuerst nur einen try-catch-Block, hab es dann aber in zwei aufgeteilt. Ich habe mir dabei gedacht, dass so etwas deutlicher wird, dass bei einem Fehler beim Verbindungsaufbau sicherlich eine andere Fehlerbehandlung stattfindet als wenn eine Datenbankabfrage schief geht. Gleiches Problem wie zuvor, zu sehr in „Kategorie Lehrbuch“ gedacht? Also lieber nur einen Block verwenden?
"Ordentliche" Systeme haben unterschiedliche Exceptiontypen, so dass man Verbindungsfehler und Statement-Fehler getrennt behandeln kann. Ich denke, für das Beispiel tut es auch ein einzelner Block für alles. Eine universelle Lösung für alle Anwendungsfälle wird es eh nicht geben.
Wir haben hier quasi das Bittersmann-Riesterer-Problem. Einerseits korrekt machen, andererseits didaktisch sinnvoll aufbereiten. Es soll schon best practice zeigen, es kann aber nicht für jeden eine kopierfähge Vorlage bieten.
dedlfix.
Rolf b
Matthias Scharwies
Auge