Warum Go?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45662 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FrOSCon 201915 / 94
7
10
12
14
15
16
17
20
22
23
26
27
28
29
30
31
32
33
36
37
38
39
41
44
45
48
52
53
55
56
57
58
60
61
62
64
66
67
74
76
77
78
79
81
83
84
93
00:00
SoftwareMORSE <Programm>XMLUMLLecture/ConferenceComputer animation
01:00
SoftwareMORSE <Programm>Computer animation
01:58
Programming languageGoogleComputer programmingCoroutineAlgorithmDataflowKommunikationC++Well-formed formulaLecture/ConferenceComputer animationXMLMeeting/Interview
02:58
GoogleComputer programmingCodeCompilerThread (computing)Block (periodic table)XMLComputer animation
04:00
Java Virtual MachineCompilerComputer programCodeOverhead (computing)Java native interfaceXMLSupremumCodeJava Virtual MachineError detection and correctionSpeciesParallel programming modelMathematicsFRAMEWORK <Programm>Run-time systemComputer animationMeeting/Interview
05:43
Web browserJavaScriptInterpreter (computing)Scripting languageServer (computing)BerechnungCompilerUiHIMPACT <Programmierumgebung>DatabaseError detection and correctionLaufzeitProduct (category theory)Set (mathematics)XMLComputer animationLecture/Conference
06:54
UDP <Protokoll>JavaScriptEncryptionParsingUniform resource locatorSet (mathematics)DatabaseJavaScriptEncryptionWEBServer (computing)XMLComputer animationLecture/Conference
07:52
HOLProduct (category theory)ImplementationSet (mathematics)Parameter (computer programming)Hand fanComputer animationSource code
09:07
CodeStack (abstract data type)CarriagewayC++SpeciesDatabaseLecture/ConferenceComputer animation
10:35
Remote procedure callUDP <Protokoll>DatabaseXMLHTMLEncryptionXMLCodeDatabaseComputer animationLecture/Conference
11:41
Apache MavenCodeSoftware developerStack (abstract data type)CarriagewayComputer animationDiagramProgram flowchart
12:53
JavaScriptComputer data loggingZugriffObject (grammar)Error messageSAP <Marke>CarriagewayPlane (geometry)Stack (abstract data type)Noten <Programm>Metra potential methodDiagramProgram flowchartXMLComputer animation
14:14
JavaScriptCodeSlide ruleGeometrischer KörperInformationIntegral elementLecture/ConferenceComputer animation
15:25
CodeDecision tree learningVariable (mathematics)CodeError detection and correctionError messageCompilerException handlingImplementationInterface (computing)Block (periodic table)Computer animationLecture/Conference
16:27
CodePlane (geometry)Negative numberCodeComputer animation
17:46
INGA <Programm>CodeTranslation (relic)Proxy serverProviderGoogleLecture/ConferenceComputer animationSource code
18:51
JUnitGroovy <Programmiersprache>Factory (trading post)Outline of industrial organizationCodeSoftware bugSource codeComputer animationLecture/Conference
22:04
JavaScriptCodeTypCodeJavaScriptLecture/ConferenceXML
23:26
JavaScriptMotherboardMAX <Programm>Lecture/Conference
24:43
Beta functionProxy serverCache (computing)Version <Informatik>UpdateCompilerLoginComputer animationSource code
27:23
DemosceneCompilerUpdateCache (computing)Proxy serverVersion <Informatik>FlagFormatiererWEBRAMCodeLecture/Conference
29:43
DemosceneJava Virtual MachineBytecodeOverhead (computing)MathematicsDatabaseBerechnungLecture/ConferenceComputer animationXML
31:49
Set (mathematics)Module (mathematics)CodeImplementationLecture/ConferenceComputer animation
33:59
ProduktdatenbankService (economics)ICONImplementationHTTPMEGACodeComputer animationLecture/Conference
34:58
ImplementationString (computer science)CodeObject (grammar)CarriagewaySAP <Marke>ImplementationXML
37:31
ImplementationHTTPUniform resource locatorSoftware repositoryCodeSQLGeometrischer KörperZahlRoute of administrationInformationComputer animationLecture/Conference
40:37
ImplementationKommunikationKommunikationComputer animation
41:36
ImplementationExponential functionKommunikationSoliDImplementationComputer animation
42:57
OvoidFunction (mathematics)Computer animation
44:18
Error detection and correctionEnergy levelThread (computing)Single-precision floating-point formatLoop (music)Internet forumThread (computing)Computer animationLecture/ConferenceXML
46:17
Thread (computing)MultithreadingCountingVariable (mathematics)CodeQuantum stateComputer animation
48:09
MultithreadingVariable (mathematics)Thread (computing)FRAMEWORK <Programm>Lecture/ConferenceComputer animation
49:22
Loop (music)CodeHTTPLecture/ConferenceComputer animationDiagram
50:39
CLOU <Programm>Loop (music)Error messageCodeParallel programming modelCodeProgrammer (hardware)DiagramLecture/ConferenceComputer animationXML
52:51
Concurrency patternComputer programmingComputer animation
54:11
Computer animationXML
55:37
KommunikationComputer animationXML
56:48
KommunikationXMLComputer animation
58:18
CoroutineFREDMassMORSE <Programm>XMLComputer animation
01:01:00
FormatiererConcurrency patternLecture/ConferenceComputer animation
01:02:50
Overhead (computing)Thread (computing)Lecture/ConferenceXMLComputer animation
01:05:02
SoftwareEnergy levelError detection and correctionComputer animationMeeting/InterviewLecture/Conference
01:06:03
Error detection and correctionDecision tree learningDatabaseSet (mathematics)Computer animation
01:09:09
CodeDecision tree learningLecture/ConferenceXMLComputer animation
01:10:09
CodeError detection and correctionComputer animation
01:11:53
Error detection and correctionDecision tree learningError messageHTTPImplementationCodeException handlingComputer animationMeeting/Interview
01:15:20
Error messageImplementationCodeException handlingError detection and correctionHTTPComputer animationXML
01:16:41
openSUSEComputer animationJSONXMLUML
Transcript: German(auto-generated)
00:00
Ich habe jetzt drei Go-Routinen, die parallel laufen. Die lauscht wieder auf diesen Kanal, der zwischen denen rumgereicht wird, als Kommunikationsweg. Nimmt sich das, was vorher rauskam, dem ist aber auch egal, was vorher rauskam, verwandelt es in Morse, in Morse-Code, und gibt das dann raus. Und am Ende habe ich so ein Ding, das lauscht eben auf diesen Morse-Code, auf der Hauptroutine, und gibt den aus.
00:23
Und das sieht dann so aus, dass ich am Anfang diesen Emitter habe, der tick tick tick macht. Der hat seinen Kommunikationsweg, den gebe ich diesem Logger rein, der gibt einen Kommunikationsweg raus, den stecke ich in den Morse-Arbeiter rein, der gibt dann einen Kommunikationsweg raus, und auf den kann ich lauschen.
00:42
Das heißt, die haben nicht so ein Stück Speicher, auf dem die arbeiten, zum Beispiel eine Liste an Strings, wo die was hinzufügen und dann muss geblockt werden, sondern die geben sich einfach so Kommunikationswege raus. Kanäle, Warteschlangen, wie man es nennen will. Und wenn ich das jetzt einmal ausführe, dann sieht das so aus, dass hier ein Morse ist. Da steht dann eine Stunde, eine Minute, eine Sekunde in Morse, sehen wir hier.
01:04
Ach so, ihr seht nicht, wo mein Finger hin zeigt, ne? Ach, ist auch rot, denkbar schlecht. Man sieht hier vielleicht, ändern sich Sachen. Und wenn jetzt das ein länger dauern würde, könnte ich diesen Flaschen jetzt ganz einfach beheben, indem ich diese Score hier in einer Schleife mache, die zweimal ausgeführt wird.
01:22
Und auf einmal laufen zwei Arbeiter, die Morse verwandeln, wenn Morse ganz lange dauern würde. Fertig. Ganz einfach. Pros und Cons. Das Ganze, was wir hier gesehen haben, ist super effizient. Das heißt, das braucht zwei Kilobreit pro Go-Routine, und die drei teilen sich die Betriebsteam-Threads.
01:44
Das heißt, für ein Java-Thread kann ich 1.000 Go-Routinen starten. Ganz cool. Und habe eigentlich keine großen Nachteile an der Stelle. Meistens brauche ich auch dieses Locking nicht. Das heißt, ich muss nicht gucken, wer benutzt was, und nur einer darf gleichzeitig zugreifen,
02:00
weil ich einfach kommuniziere zwischen diesen Routinen. Aber wenn ich das brauche, kann ich das auch. Es gibt auch dieses Locking, gibt es auch in Go. Für manche Algorithmen ist das notwendig. Und für manche extrem hoch effiziente Algorithmen ist das notwendig. Die sind dann schneller als diese Routine. 95 Prozent der Fälle reicht die Kommunikation. Und der Datenfluss ist transparent.
02:21
Ich habe gesehen, ich habe die Sachen von oben nach unten zusammengesteppselt. Es war klar, wer kommuniziert mit wem. Es war sehr, sehr klar lesbar, und es ist nicht irgendwie eine Magic im Hintergrund. Das hat einen Nachteil, der ein bisschen absurd ist, weil das so einfach ist, neigen besonders Anfänger dazu, das zu viel zu nutzen. Also ich muss nicht zum Ausdrucken von einem String, wie ich gerade,
02:41
eine parallele Routine irgendwo starten oder fünf oder so, sondern ich kann es auch einfach reinschreiben, jetzt druckt das aus. Keep it simple, stupid. Aber wenn man das ein bisschen benutzt hat, lernt man das auch. Also, kurze Zusammenfassung. Was parallelität angeht, ist Go einfach zu lesen, oben nach unten. Ganz klar, was nacheinander passiert, wenn auch parallel.
03:04
Es ist einfach zu maintain, weil einfach zu lesen bedeutet, einfach zu maintain. Ich kann drei Monate noch mal hingehen und verstehe das. Sogar Code, den ich nicht geschrieben habe, vor allem weil er gleich formatiert ist. Es ist einfach zu schreiben, weil Go hat sehr, sehr wenig Sprachwörter,
03:20
wenig, was ich lernen muss. Das, was ich da lese oder das, was ich da schreibe, kann jeder auch wieder verstehen. Ich muss mir wenig Gedanken machen, ob mein Kurs lesbar ist. Also, natürlich muss ich mir Gedanken machen. Und es ist super effizient, wie gesagt zwei Kilobyte statt zwei Megabyte. Und kompiliert. Ja, war es auch einfach zu lesen. Also was wir da gesehen haben mit dem Synchronized und so, das sind einfach Blocke von oben nach unten und Threads.
03:42
Auch relativ einfach zu lesen. Aber leider schwer zu maintain, weil die Implikationen, die da mitschwingen, bei so einem Wolle-Teil und Synchronized, besonders bei großen Code-Basen, leicht übersehen werden. Da muss man aufpassen, dass man da keine Fehler macht. Besonders mit diesem Wolle-Teil habe ich bisher jedes Mal, wenn es genutzt wurde, gab es einen Bug auf Produktion bei mir, wo ich das gesehen habe.
04:02
Und entsprechend ist es schwer zu schreiben, weil man will es verständlich schreiben. Man will, dass es einfach zu lesen bleibt. Und umso größer es wird, umso komplizierter wird das. Und bei der Ausführung habe ich da diesen Thread-Overhead. Das heißt, ich kann nicht einfach mal eben 1000 Threads hochziehen. Das sind 3 GB RAM, 2 bis 3. Ich glaube, es ist ein bisschen besser geworden. Aber ich bleibe jetzt mal so plakativ.
04:23
NodeJS ist wiederum schwer zu lesen. Also wenn ich das einmal schreibe, fühlt sich das super cool an. Also leicht zu schreiben. Aber wenn ich den Code in drei Wochen angucke oder WM gebe, dann sind da ganz viele kleine Callbacks, die irgendwann passieren. Ich weiß nicht, was wann passiert, das ist typlos. Ich weiß nicht, darf das eigentlich so sein? Super schwer. Und deswegen ist es auch schwer zu maintain.
04:42
Auch aus eigener Erfahrung. Und der Vorteil mit den lang dauernden IO-Operationen ist super cool. Dateien lesen so passiert irgendwann, muss ich mir Gedanken darüber machen. Aber wenn ich auf einmal Mathematik mache, super abgefahren, dann wird es schwer. Dann muss ich auf einmal selber Parallelisierung programmieren, sorry.
05:03
Vielen Dank und wir springen jetzt asynchron zurück. Und nutzen noch die restlichen Minuten. Ich drücke das jetzt in fünf Minuten durch. Der Code zum Beispiel, den Dino gerade so schnell durchgezeigt hat, der ist auch bei GitHub. Also ihr könnt ihn noch mal in Ruhe nachvollziehen zuhause.
05:22
Bei einem kühlen Bier oder Wasser, wie auch immer. Ja, genau. Wenn ihr irgendwelche Termine oder so habt, dann geht ruhig. Ich bin euch nicht böse. Genau, bleibt. Fehlerbehandlung. Also, was mache ich mit Fehlerbehandlung? Fehler passieren. Und es gibt, grob gesagt, zwei Arten von Fehlern.
05:43
Die Fehler, die man syntaktisch lösen kann in einer kompilierten Sprache. Oder die man überhaupt schon zur Compile-Zeit lösen kann. Auch logische Fehler. Und welche, die man nur zur Laufzeit lösen kann. Oder die nur zur Laufzeit auftreten. Zum Beispiel, die Datenbank ist weg. Das kann man nicht programmieren, das kann man behandeln,
06:00
aber man kann sie nicht vermeiden. Fangen wir mit Fehlerbehandlungen ja an. Ja, geht das jetzt schnell durch. Wir entwickeln unseren Produkt-Service weiter. Wir wollen ja einen Schritt nach vorne machen und nicht nach hinten. Also wollen wir jetzt auch noch einen Shopping-Card zur Verfügung stellen, wo wir Produkte reintun. Wir erwarten eine User-ID, eine Produkt-ID und die Menge.
06:24
Dann laden wir den Shopping-Card für den Benutzer. Laden das Produkt. Packen das Produkt so oft in diesen Shopping-Card wie gefordert. Und persistieren diesen Shopping-Card, damit wir nachher noch wissen, was da drin ist. Fällt euch an, was da schiefgehen könnte?
06:41
Ich helfe euch. Zum Beispiel der Shopping-Card für den Benutzer. Den gibt es gar nicht. Oder ganz viele andere Sachen. Die Verbindung zur Datenbank schlägt fehl. Es gibt kein Produkt mit der ID. Die Verbindung zur Datenbank ist fehlgeschlagen. Die Menge amount ist negativ, weil es keine unsigned integer gibt in Java.
07:00
Die Verbindung zur Datenbank ist fehlgeschlagen. Was machen wir? Um zum Beispiel den Fehler vorzubeugen, dass ein Shopping-Card nicht existiert, können wir in Java sagen, versuch einfach mal diesen Shopping-Card zu laden. Es könnte aber sein, dass eine Ausnahme, eine Exception passiert. Die heißt no-card-exception.
07:20
Und wenn das so ist, dann erstelle einfach einen neuen Shopping-Card für diesen Benutzer. Würde man jetzt wahrscheinlich im Produktivcode ein bisschen anders lösen, auslagern, ist aber in dem Fall egal. Genau. Hier können aber noch andere Sachen passieren, wie wir eben gesehen haben. Die Datenbank kann weg sein. Es gibt das Produkt nicht. Das sind alles Sachen,
07:40
die können wir in diesem Kontext gar nicht lösen. Wir wissen nicht, was wir da machen sollen. Da muss sich jemand anders drum kümmern. Im Zweifel muss der Server sagen, geht nicht, probier nochmal. Oder geht nicht, kündige den Admin. Deswegen sagen wir hier in dieser Funktion, wirft diese Fehler weiter nach oben. Das ist in dieser Situation sehr schön gelöst. Denn ich als Benutzer dieser Funktion sehe,
08:02
ok, ich füge hier Produkte in den Cards hinzu. Es können aber diese Sachen hier auch schief laufen. Das heißt, wenn ich das benutze, werde ich schon gewarnt, diese Randfälle gibt. Auf der anderen Seite, wir machen wieder einen HTTP-Händler. Und hier
08:20
erstellen wir einen Card-Request aus dem HTTP-Request. Holen aus diesem Card-Request die User-ID, die Produkt-ID und die Menge. Führen unsere Funktion aus. Um das, was wir eben programmiert haben, auszuführen. Hier, in diesem ganzen Ding, also sowohl hier als auch hier, kann irgendwo darunter
08:41
eine Illegal Argument Exception passieren. Zum Beispiel, wenn der Amount negativ ist. Das ist etwas, das wollen wir nicht. Dann sagen wir per HTTP, das ist dein Fehler. Du hast was kaputt gemacht. Wenn irgendeine andere Exception passiert, wie zum Beispiel die Datenbank, dann sagen wir, sorry, unser Fehler. Versuche irgendwann einfach
09:01
mit den gleichen Parametern nochmal. Es ist also sehr übersichtlich getrennt. Hier ist unsere Implementierung und hier ist unser Fehlerhandling. Was passiert, wenn wir so eine Exception nicht fangen? Na ja, in Java kriegt man dann so einen Stack Trace. Das Gemeine bei so einem Stack Trace, also hier sieht man, der hat den aufgerufen, der hat den aufgerufen, den, den, den.
09:22
Hier in dem Code können wir das nachlesen. Es kann aber passieren, wenn wir Exceptions fangen und wieder werfen, dass der eigentliche Grund für diese Exception nicht der unterste ist, sondern irgendwo in der Mitte. Das heißt, man hat relativ viel zu lesen. Ich arbeite mit zwei Java-Entwicklern im Team. Wir machen zwar nur Go, aber die haben vorher Java gemacht.
09:41
Und die können das unfassbar schnell lesen. Und ich sehe nur das und denke, kann mir bitte jemand von den Java-Entwicklern helfen? Ja. Wir haben gerade gesehen, die Funktion definiert genau, was schiefgehen kann. Nachteil dieses Vorgehen ist, jedes Mal, wenn jemand, den ich hier aufrufe,
10:01
irgendeine andere Exception wirft, muss ich das hier aktualisieren, sonst kompiliert der Code nicht mehr. Denn ich sage, diese drei Arten werden geworfen. Es gibt noch eine andere Möglichkeit, damit umzugehen. Ich sage nicht, diese drei Arten werden geworfen, sondern Exceptions werden geworfen. Exceptions sind auch polymorph. Und wenn ich sage, Throws Exception, können das auch diese drei sein.
10:21
Können aber auch ganz andere sein. Ganz egal. Der Vorteil, das so explizit zu sagen ist, ich sage, was kann schiefgehen. Du benutzt das, dann pass mal auf, könnte eine Datenbank meckern, oder weiß ich nicht was. Entwickler werden genau darauf aufmerksam gemacht und werden darauf aufmerksam gemacht. Sehr gut.
10:42
Throws Exception ist viel flexibler. Also wenn irgendjemand in einer Library, die ich benutze, und das können ganz viele Libraries sein, irgendwas ändert, muss ich meinen Code nicht ändern. Der kompiliert immer noch. Auf der anderen Seite weiß ich natürlich nicht genau, was alles schiefgehen kann. Und ich weiß nicht genau, welche Randfälle ich betrachte.
11:01
Eben haben wir zwei Randfälle gehabt, wo wir einen 500er und einen 400er geworfen haben. Das muss man sich dann eher denken. Also, Exceptions sind Java. Wir haben alle Randfälle behandelt oder reichen sie explizit nach oben. In unserem Beispiel. Allgemeine Fehler wie Datenbankverbindungsfehler werden an einer Stelle behandelt. Nicht überall im Stackrace. Ich prüfe nicht immer mal, was mache ich denn jetzt?
11:22
Datenbank geht nicht. Sondern ich mache es nur ganz oben, da wo ich es auch wirklich behandeln kann. Es ist möglich Fehlerhändling von dem Normalfall zu trennen. Das haben wir gesehen. Wir haben erst den ganzen Ausführungscode und dann haben wir ganz viele Catches. Es ist möglich, Fehlerfehle zu gruppieren, wie zum Beispiel Illegal Argument Exception. Der Amount könnte
11:41
negativ sein. Oder sagen wir einfach mal, eine Produkt-ID wurde benutzt, die es so syntaktisch gar nicht geben kann. Beides eine Illegal Argument Exception. Beides resultiert in einem 400er. Wie ist das in Go? So, was ist das? Das ist die gleiche Deimplementierung der
12:02
AddProductToCard. Das ist aber ganz schön viel Code. Eben hatten wir nur 5 oder 6 Zeilen. Naja, gut. Es hat sich eben gesagt, ich arbeite mit zwei Java- Entwicklern im Team. Die fanden es die ersten vier Monate auch richtig scheiße, dass das so explizit ist. Mittlerweile
12:21
lieben sie es. Also, man muss sich da auch ein bisschen dran gewöhnen. Wenn man jahrelang anders gearbeitet hat, ist das eine große Umgewöhnung. Das will ich nicht verschweigen. Teilen wir das mal visuell ein bisschen ein. Alle Fehlerfälle oder Anormalitäten sind eingerückt. Das, was passiert, sehe ich hier alles auf der Golden
12:41
Line. Golden Line of Sight nennen wir das. Wenn man sich daran gewöhnt hat, so wie Java- Entwickler Exception Stack Traces lesen können, was ich nicht kann, lernt man als Go-Entwickler erstmal die nicht eingerückten Sachen zu lesen. Dann weiß man, okay, AddProductToCard lädt einen Shopping Card, lädt das Produkt, packt das da rein, persistiert das, genauso wie es in Java der Fall war.
13:03
Was sehen wir noch? Errors sind explizite Objekte. Dann nennen wir es mal Objekte. Das heißt, wir haben einen Rückgabewerterror. In Java hatten wir zwei Flussebenen. Die eine Flussebene waren die Return Values und die andere Flussebene waren Exceptions. Wenn irgendwo eine Exception geworfen
13:20
wird, wird die Ausführung unterbrochen. Das ist in Go nicht so. In Go gibt es nur eine Ebene. Wir führen das hier aus. Wir laden den Shopping Card für den Benutzer, kriegen einen Fehlerwert, den wir dann auch immer überprüfen müssen. Hier gucken wir, ist das ein Not Found Error? Wenn das der Fall ist, dann erstellt einfach einen neuen Card.
13:40
Ist das eine andere Art von Fehler? Pff, gib's zurück. Ich weiß nicht, was ich damit machen soll. Aber reicher ist, mit Load Shopping Card fällt an. Das heißt, auch hier ist ein Unterschied. Bei Java wirft man einfach die Exception und dadurch wird der Stack Trace automatisch angereichert. In Go macht man das selber. Hat den Nachteil, man muss es selber machen. Hat den Vorteil, am Ende
14:00
des Tages habe ich nicht 500 Zeilen Exception Stack Trace, sondern da steht, konnte das Produkt nicht zum Shopping Card hinzufügen, Doppelpunkt, Loading Shopping Card Fail, Doppelpunkt, Database Connection Closed. Also, ich habe das auf die wesentlichen Informationen eingenimmt, aber ich musste
14:21
selber dafür sorgen. Hier gehen wir weiter. Wir laden das Produkt, haben wieder einen Fehler, müssen gucken, ob der nicht nil ist und so weiter. Auf der anderen Seite machen wir wieder einen HTTP-Händler. Der holt sich die Request Data. Wenn das nicht funktioniert, sagt 400, du hast mir
14:41
Invalides Jason geschickt. Dann füge ich diese Funktion wieder aus. Wenn ich merke, dass es ein Bad Input, write 400. Wenn ich merke, das ist irgendwas anderes, 500. Also, da habe ich jetzt den Body außen vor gelassen, weil die Slides so klein sind. Also, vergleichen wir das alles nochmal in Go.
15:00
Wir haben sehr, sehr viel Code. Kann einen ein bisschen erschlagen am Anfang. Es ist sehr explizit. Man muss kein mentales Modell im Kopf haben. Man kann es einfach lesen. Es ist also nichts für Leute, die gerne cleveren Code schreiben, sondern Leute, die gerne verständlichen Code schreiben. Fehler müssen bei mehreren Rückgabewerten explizit ignoriert werden. Wir sehen das hier.
15:24
Wenn ich den Cart einer Variable zuweise, muss ich hier einen Unterstrichen malen, wenn ich den ignorieren möchte. Und wenn ich hier Error befülle, muss ich Error auch verwenden, sonst meckert der Compiler. Also, unused Variables gibt es nicht.
15:40
Das hat man eben in dem anderen Beispiel gesehen. Da hatte ich ein paar Mal den Unterstrich, damit der Code nicht so aufgebläht ist. Trennung von Ausführungs- und Ausnahmebehandlungen durch Einrückungen, aber auch nur durch Einrückungen. Also, man muss das ein bisschen lernen, es zu lesen, aber es gibt eine Trennung. Verschiedene Fehlerarten müssen durch Interfaces abgebildet werden. Das habe ich euch jetzt ein bisschen verschwiegen, aber
16:02
Error ist ein Interface und dadurch, dass Interfaces implizit implementiert werden, kann das natürlich auch noch andere Interfaces erfüllen. Und hier prüfe ich, ob das das IsBadInput-Interface erfüllt. Java. Trennung von Implementierung und Fehlerbehandlung durch Try-Catch- Blöcke. Fehlertracing kann unübersichtlich sein. Welche Zeile hat die Exception geworfen?
16:22
Durch Polymorphie der Exceptions kann der Entwickler entscheiden, wie flexibel beschreibend die Schnittstelle sein soll. Also, Negative Amount Exception kann Illegal Argument Exception extenden. Und dann kann ich immer noch entscheiden, auf dieser Ebene interessiert es mich, dass der Illegal Argument Exception wirft oder Negative Amount.
16:42
Das war's schon. Vielen Dank.