Exception Handling in Multi-Layered Systems

This is the first blog post here which is completely in English. And of course there is a reason for that. I currently don’t plan to do this regularly (maybe I should? I don’t know.). Anyway, here is the reason: Next week I’ll give a talk for the Australian Delphi User Group in Sydney. The talk will be a webcast, which means, I’ll stay here in Germany while the audience will be sitting on the other side of the globe. ADUG members who cannot be in Sydney can also attend using the web streaming system.

What am I talking about? If you are reading my blog, you should recognise the topic:

Title: Exception Handling in Multi-Layered Systems
Abstract (or maybe I should rather say “teaser” or something):
How do you structure software properly? Why should we think about the structure of a software? And how? How to handle exceptional cases? Is the Exception language feature always the best way? This talk has roughly two parts. In the first part we will have a look at architecture, layers and tiers. The second part deals with exceptions and how to use them properly. In the end we will see what the one has to do with the other.

Errata:

• There is a typo on slide 17: it should read “defines” instead of “defined”.
• Slide 22 is not translated (sorry for that). The note there means “Weak layering: Layer 3 may directly access Layer 1.”

This is basically the same talk I gave at the Delphi-Tage this year in Heidelberg. After my presentation in Heidelberg, Mathias Burbach, the president of the ADUG, approached me and asked if I could also give this talk in English. And so I do. The contents will be basically the same, although there are some minor changes.

Again there are slides and more elaborate talk notes:

Download: Exception Handling in Multi-Layered Systems (Slides) (Größe: 3.08 MB; bisher 109 mal heruntergeladen)
Download: Exception Handling in Multi-Layered Systems (talk notes) (Größe: 3.08 MB; bisher 195 mal heruntergeladen)

I haven’t had the time to translate everything, so the German talk notes are still more detailed (roughly eight pages more).

While translating, I also realised that by now I’m already more used to American English than the British one. In school I mainly learned the British version but in university I almost exclusively hear, talk, read and write AE. Wikipedia says Australian English is pretty much like BE, so I’ll try to get used to that variant again. Let’s see how good that works.

As always I’m highly interested in feedback of any kind. Tell me what you like but especially also what you didn’t like. I can only get better when I know where to improve. Don’t hesitate to mention even spelling mistakes or the like. I’m happy to hear about everything I can do better.

Update (24th November): Maybe I should share my impressions of the talk. I like giving talks and giving this one in English via a web stream was a quite interesting experience. The English talks I gave until now where about half an hour, so this one lasting 55 minutes (+discussion) was quite a bit longer. Nevertheless it proved to be not much of a difference. As far as I remember I haven’t been looking for words, etc. So I’m quite satisfied with the language although German is still a bit more comfortable for me.

Due to some technical problems, I had to interrupt my talk to wait for a part of the audience rejoining. This made me hurry up a bit to keep the time frame. I tried to do this in those parts of the talk the audience most likely was already familiar with. But I’m afraid I was a bit fast anyway.

Web streaming the talk in my eyes had two effects: a positive one and a negative one. The negative one is that I could not see the audience and thus could not react to whether they looked bored or confused or rejecting or whatever. Normally a good presenter should keep an eye on how the audience reacts. Here I didn’t have the opportunity to do so. The second effect I believe to have encountered was that not seeing the audience made me avoid saying “erm“. Normally I use this “erm” a lot (and I try to stop that). During the talk I found myself rather making an actual pause or speaking slower instead. This is good. My guess is that not seeing the audience makes me less feel the need to make this sound as it normally just works as a signal which says “Don’t interrupt me, I haven’t finished talking yet.” But maybe I also just have a wrong impression. I didn’t concentrate on this aspect as language was more important.

At the end there was the opportunity for discussion but there was only one question. Unfortunately in my eyes I didn’t answer this question well. It was actually pretty bad. So after the break I tried to give a better answer.

Like so often, feedback is scarce. It’s a pity. I’d love to hear some comments on my presentation style, my English, the topic, etc. Even negative comments. The above is just my impression and maybe it’s wrong. Most likely there are also aspects I don’t realise, so feedback is always good if you want to improve.

Fehlerbehandlung in mehrschichtigen Systemen

… oder kurz: Schichten und Exceptions

Die Delphi-Tage 2012 sind zu Ende. Wie üblich hab ich nen Vortrag gehalten. Diesmal gings um Schichten, um Exceptions und was das eine mit dem anderen zu tun hat.

Abstract:
Wie strukturiert man eigentlich Software? Braucht Software überhaupt eine Struktur? Und, wenn ja, wie kann die aussehen? Und wie behandelt man eigentlich Fehler und Ausnahmesituationen? Sind Exceptions hier das Maß aller Dinge? Wie setzt man sie richtig ein? Und was hat das Ganze mit Schichten zu tun? Dieser Vortrag gliedert sich in zwei Teile. Im ersten Teil wird gezeigt, wie man Software in Schichten strukturieren kann und welche Vorteile das hat. Außerdem werden ein paar Buzzwords wie “Architektur”, “Layers” und “n-Tier” geklärt. Der zweite Teil befasst sich mit Exceptions, wie man diese richtig einsetzt und was das Ganze mit Schichten zu tun hat.

Resümee:
Ich halte gerne Vorträge und noch lieber halte ich sie, wenn interessiertes Publikum vorhanden ist. Und das war es. Und es hat Spaß gemacht. Der Raum war voll und das obwohl die parallel stattfindenden Vorträge sich eigentlich auch sehr interessant angehört haben. Was mich besonders gefreut hat, war, dass es viele gute Fragen gab. Es ist immer schön zu sehen, wenn man mit dem Thema etwas getroffen hat, das nicht nur einen selbst interessiert.

Von meiner Seite aus muss ich sagen, dass eigentlich alles ziemlich gut geklappt hat. An Details kann man natürlich immer feilen. Deshalb mal wieder die Bitte um Feedback. Diverse positive Rückmeldungen hab ich schon bekommen (was mich sehr gefreut hat). Da ich mich aber nur verbessern kann, wenn ich weiß, was nicht so gut war, bitte ich auch und insbesondere um negatives Feedback. Was war nicht den Erwartungen entsprechend, was war verbesserungswürdig, unnötig oder unverständlich? Was hat gefehlt?

Folien und Vortragsnotizen:
Ich habe diesmal getrennte Folien und Vortragsnotizen. Auf den Folien steht nicht sonderlich viel drauf, was sie für den Vortrag passender gemacht hat (denke ich zumindest). Dafür gibts zusätzliche Vortragsnotizen. Diese sind demgegenüber ausführlicher und enthalten teilweise sogar ganze Textabsätze. Das ist jetzt nicht so detailliert und ausgefeilt wie ein Tutorial, aber es sollte ausreichen, um auch verständlich zu sein, ohne dass man den Vortrag gehört hat. Feedback hierzu ist natürlich auch willkommen. Also hier die Downloads:
Download: Schichten und Exceptions: Folien (Größe: 2.99 MB; bisher 160 mal heruntergeladen)
Download: Schichten und Exceptions: Vortragsnotizen (Größe: 3.05 MB; bisher 184 mal heruntergeladen)

Hinweise:

• Danke für den Hinweis, dass in den Folien ein “Create” gefehlt hat. Ist jetzt korrigiert.
• Nach dem Vortrag würde ich noch auf EurekaLog als Alternative zu madExcept hingewiesen. Der Hinweis findet sich nun auch in den Vortragsnotizen.
• Ebenfalls vielen Dank für den Hinweis, dass man die UML-Packages, die erstmal ja nur eine logische Gruppierung darstellen, mit Delphi-Packages umsetzen kann. Der eigentlich passende Mechanismus wären IMHO wohl Namespaces, die es in Delphi in der Form nicht gibt. Und wenn man sich .NET und Java ansieht, wird man feststellen, dass es dort beides gibt: Namespaces/Java-Packages und Assemblies/jar-Dateien. Beides, logische und physische Gruppierung, ist orthogonal, d.h. vollkommen unabhängig voneinander. So kann eine Assembly mehrere Namespaces enthalten und umgekehrt. Dabei ist die physische Gruppierung die eindeutig schwergewichtigere. Trotzdem halte ich das für einen wertvollen Hinweis. Man sollte sich durchaus überlegen, ob Delphi-Packages nicht doch in Frage kommen, um einzelne Schichten/Packages voneinander zu entkoppeln. Ist wohl eindeutig eine Überlegung wert.
• Die Graphik mit dem schlecht wartbaren Subsystem wurde mit einer Software des Fraunhofer IESE erstellt. Links dazu sind in den Vortragsnotizen.
• Zwei “Problembereiche” von Exceptions wurden noch angesprochen: DLLs und Threads. Ich hab nochmal nachgeguckt, aber leider hab ich keine Links dazu parat. Und ein Patentrezept hab ich leider auch nicht. Von daher kann ich wohl nur wiederholen, was ich schon als Antwort gegeben hatte: Exceptions an DLL- und Threadgrenzen vermeiden (noch mehr als sonst) und ggf. auf die anderen Fehlerbehandlungsmechanismen ausweichen (Fehlercodes, OnError-Events, etc.). Man könnte sich auch andere Ausweichstrategien überlegen. Beispielsweise Records mit den Fehlermeldungen zurückgeben, Window-Messages verschicken, etc. Auch kann man sich um ne DLL auf der Aufruferseite wieder einen Wrapper schreiben, der Fehlercodes, die als Ausweichstrategie verwendet wurden, wieder in Exceptions umschreibt. Leider gibt es wohl keine perfekte Lösung. Was im konkreten Fall nun vorzuziehen ist, hängt dabei wohl auch stark von den jeweiligen Rahmenbedingungen und Anforderungen ab.
• Testgetriebene Entwicklung/Test-First-Ansätze wurden erwähnt. Genau genommen unterscheide ich zwischen den beiden Begriffen (was nicht alle tun). Vielleicht mach ich dazu mal nen separaten Blog-Post darüber. Vereinfacht gesagt geht es darum, den Test-Code zuerst zu schreiben. Und das hat dann Auswirkungen auf das Design. Eigentlich geht es noch um viel mehr. Weil ich das aber hier nicht alles erwähnen kann, verweise ich lieber auf Wikipedia, die einschlägigen Blogs und diverse Bücher zum Thema.
• Zu Assertions hab ich letztes Jahr schon ein bisschen was gesagt. Außerdem kann ich auf das auch anderweitig unbedingt zu empfehlende Buch “The Pragmatic Programmer” verweisen. Da gibts auch ein kleines bisschen etwas dazu. Im übrigen sind Andrew Hunt und David Thomas auch meiner Meinung, dass man Assertions nicht unbedingt deaktivieren muss.
• Design by Contract wurde auch kurz erwähnt. Hier ein passender Link dazu.
• Ich hoffe, ich hab hier nichts vergessen. Vielen Dank jedenfalls auch für die anderen Kommentare.

Nachtrag:
Eine Möglichkeit zur Verbesserung ist mir gerade selbst noch eingefallen: Mit einem Laserpointer würde sich wohl deutlich besser auf die Leinwand zeigen können als mit der Hand. Ich glaub, ich sollte mir für nächstes Jahr so ein Ding zulegen. Ansonsten würde ich gerne wissen, ob ich verständlich war. Sowohl inhaltlich alsauch sprachlich. War ich zu schnell, zu langsam, zu laut, zu leise? Wie war meine Körperhaltung und keine Ahnung was… Ich bitte auch um Kritik an Kleinkram.

Eiffel: Das Esperanto unter den Programmiersprachen

Ich gehöre zu denjenigen, die sich gerne immer mal wieder eine neue Programmiersprache ansehen. Nicht um in jeder dieser Programmiersprachen letztendlich auch produktiv zu arbeiten, aber um mal “übern Tellerrand zu gucken”.

Das Ganze ist nicht nur interessant, sondern hat auch den Vorteil, dass man sehr viel über unterschiedliche Herangehensweisen und Programmierkulturen erfährt. Die einzelnen Sprachen unterscheiden sich nicht nur in der Syntax, sondern auch in der Denkweise, wie Probleme gelöst bzw. Code geschrieben wird. Sowas ist manchmal augenöffnend und kann auch mal helfen, kreative Lösungen für schwierige Probleme zu finden, die man in “seiner” Programmiersprache hat.

Das heißt natürlich nicht, dass man anfangen sollte, die eigene Sprachkur zu missachten. Im Gegenteil: Manchmal ist es sinnvoller, eine schlechte, aber allseits bekannte Lösung zu verwenden, als eine elegante, die für andere Entwickler “fremdartig” wirkt. Code schreibt man i.d.R. ja nicht nur für sich selbst, sondern auch für die anderen Entwickler im Team, etc.

Aber für schwierige, nicht-alltägliche Probleme kann man auch mal eine kreative Lösung gebrauchen. Und dafür ist es ganz gut, wenn man mit anderen Sprachen und Programmierkulturen in Kontakt kommt. Außerdem ist es mit Programmiersprachkulturen ähnlich wie mit natürlichen Sprachen: Sie verändern und beeinflussen sich gegenseitig und das ist eine Bereicherung. [1]

Ich bin nicht der einzige, der so denkt. In “The Pragmatic Programmer” [2] geben Andy Hunt und Dave Thomas den Rat: “Learn at least one new language every year.” Und da komm ich sogar in etwa hin. Die meisten davon kann ich nicht (mehr) wirklich gut. Wirklich produktiv einsetzen kann ich momentan davon nur ne Hand voll. Aber darum gehts ja auch nicht.

Nun, ich hab mich jetzt ein bisschen mit Eiffel beschäftigt. Aus Zeitgründen leider nur oberflächlich. So hab ich praktisch keinen echten Code geschrieben sondern nur Tutorials und Code gelesen. Das bedeutet natürlich, dass viel von der Syntax bald wieder verflogen sein wird. Aber wie gesagt: Darum gehts mir gar nicht.

Ich hab also einen Eindruck von Eiffel bekommen. Um jetzt mehr als ein Bauchgefühl vermitteln zu können, müsste ich wohl wirklich mal ein paar hundert Zeilen Code schreiben. Aber dafür hab ich momentan keine Zeit. Hier also nur mal ein erster Eindruck. weiter lesen »

Gefangen, nicht gefunden! #13

Irgendwie komm ich kaum noch zum Bloggen. Mein Semester hat wieder angefangen und meine Zeit ist wieder sehr begrenzt. Hier aber zumindest mal ein kleines bisschen was.

Informatik

• Using Interfaces for Exception Safety in Delphi
• Interessanter Blog-Post zu MySQL: Red vs Blue at Oracle, und ein paar Gedanken zu Postgres

Anderes

• Typographie für Präsentationen. Das meiste ist altbekannt und gilt genauso für “normale” Texte. Dennoch eine schöne Zusammenstellung.
• In der Erzählung “Die Bibliothek von Babel” beschreibt Jorge Luis Borges eine Bibliothek in der alle prinzipiell möglichen Bücher (einer gewissen Länge) stehen. Das heißt jedes Buch, das sich aus den Buchstaben des Lateinischen Alphabets zusammensetzen lässt, ist dort vertreten. Von dem Buch das nur aus Leerzeichen besteht über Goethes Faust bis zum unnützen Kauderwelsch zufälliger Buchstaben. Mal davon abgesehen, dass die Erzählung an sich schon lesenswert ist, hab ich letztens mal eine mathematische Betrachtung dessen gefunden: Die Bibliothek und Goedel. Sehr interessant. Insbesondere der zweite Teil über die Größe der Bibliothek veranschaulicht schön die Grenzen der menschlichen Vorstellungskraft.
• Merkwürdiger Kommentar-Spam: Nichts-sagender Satz von ner russischen IP mit dem gmail-Konto und nem Link zu Google. Hä?

Gefangen, nicht gefunden! #6

Informatik

• So langsam gewöhne ich mich an git. Der Ansatz gefällt mir außerordentlich gut. Allein schon die Möglichkeiten von git log sind erstaunlich.

  1	user@host:~/rep$ git log --since="2009-01-01" --until="two months ago"

  Es dauert allerdings etwas, bis man sich an git gewöhnt. Anfangs wird man fast von den vielen Möglichkeiten erschlagen und so kann ich noch lange nicht sagen, dass ich schon das meiste kann, aber die grundlegenden Sachen sind nicht viel schwerer als bei SVN…

• Wenn ich schon bei git bin, dann soll natürlich das Git-Buch nicht verschwiegen werden: book.git-scm.com Auch hier gibts dazugehörige Videos. Diese sind ein ganzes Stück ausführlicher als der Text und scheinen nachvertont zu sein. Das Video ist oftmals einen Tick schneller, sodass während über das eine Kommando gesprochen wird, schon das nächste da steht. Trotzdem sehr empfehlenswert.
• Durch eines der Videos ist mir aufgefallen, dass ich ein interessantes bash builtin bisher noch nicht kannte. Mit pushd kann man wie mit cd in ein neues Verzeichnis wechseln, allerdings wird das alte auf einen Stack gelegt. Mit popd kann man es wieder vom Stack nehmen und dirs zeigt den Inhalt des Stacks an. Man page lesen lohnt sich.
• Ich habe schon wieder in einem C++-Projekt vergessen einen virtuellen Destruktor zu vergeben und dadurch ein Speicherleck produziert. Warum erzeugt der doofe Compiler da keine Warnung? So schwer sollte das doch nicht sein…
• Exceptions sind toll. Sie helfen ungemein Fehlerbehandlung und eigentlichen Code zu trennen und machen den Code lesbarer wartbarer und robuster. Ich benutze Exceptions sehr gerne. Aber wo Licht ist, ist auch Schatten: Exceptions sind manchmal nicht ganz einfach richtig zu verwenden. Ein interessanter Artikel über Exception Safety zeigt das.

Fehlermeldungen in Delphi

Jeder kennt sie und jeder, der anfängt zu programmieren muss sich mit ihnen auseinandersetzen. Die Rede ist von Fehlermeldungen. Vom Programmier-Einsteiger werden sie gefürchtet oder sogar gehasst, für den, der sie aber kennt, sind sie eine unverzichtbare Informationsquelle.
weiter lesen »