Schlechte Fehlerbehandlung in C#, Java & Co [Mit Beispiel] Clean Code Tipp #14

Fehlerbehandlung ist ein Bereich von Clean Code, der nicht unbedingt Deinen C#, Java, JavaScript, TypeScript oder sonstigen Code besser macht, sondern Dir dabei hilft auch in Zukunft noch viel Zeit für noch mehr Clean Code zu haben. Wir schauen uns in diesem Clean Code Tipp der Woche an, warum Ausnahmebehandlung so wichtig ist und welche Konsequenzen es hat, wenn Du die Ausnahmebehandlung nicht richtig umsetzt. Dabei wird versucht die Sprachen C#, Java, JavaScript, TypeScript, Scala, PHP, C++ und viele weitere zu berücksichtigen, so das auch jeder etwas von diesem Tipp hat. Viel Spaß!
▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬
Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)
▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬
Wie viel Softwarequalität Ihr braucht - • Architekturen - Von Mo...
Warum Software unwartbar wird - • Warum Software unwartb...
Architektur - Modularisierung - • Architektur - Modulari...
Was ist Architektur - • Was ist Architektur?
Warum Architektur - • Warum Architektur für ...
▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬
Abonniere meinen Kanal: / @davidtielke
Alle Videos: / @davidtielke
▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
► Twitter: / davidtielke
► Xing: www.xing.com/p...
► LinkedIn: / david-tielke-06140912b
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

[@techniksupportskp3374]

Ich entwickle Filemaker. Der Nachteil: die meisten Entwickler sind Quereinsteiger, so auch mein Vorgänger. Da Filemaker nach Fehler nicht einmal Abbricht und mein Vorgänger auch gar keine Erkennung für Fehler eingebaut hat, fallen manche Fehler erst Wochen nach der Ausführung auf, wenn beispielsweise wichtige Daten fehlen. Ein sehr teurer Spaß nun für die Firma, diese ganzen Fehlerbehandlungen nun einzubauen

[@marcelschneider2681]

Wir nutzen exzessiv dedizierte Exceptions für unterschiedliche Fehler und Tools wie Sentry, wo alle Informationen zu einem Fehler gesammelt und dann in Jira überführt werden können. Durch die dedizierten Exceptions haben wir zudem die Möglichkeit, diese auch schnell zu bewerten, wie schnell ein Fehler behandelt werden muss.

[@DavidTielke]

Hey Marcel, dann kannst Du Dir vermutlich den Tipp in der nächsten Woche sparen ;) Darf man fragen wie viel % Ihr so im Schnitt mit Support verbringt? Gruß David

[@marcelschneider2681]

@@DavidTielke Hi David, zum Glück werten wir das genau aus. 😉 Es sind im Durchschnitt 6% des Sprints.

[@DavidTielke]

Hey Marcel, dann Glückwunsch - ihr habt alles richtig gemacht :) Ich hoffe Du weißt das zu schätzen ;) Gruß David

[@aligarh004]

Bei uns in der Firma wird die Behandlung der Fehler leider auch recht schlecht umgesetzt. Ausserdem sind wir Entwickler auch gleichzeitig die Supportler, was die Entwicklungsgeschwindigkeit drastisch reduziert.

[@DavidTielke]

Hey Bob, wie viel % seid Ihr denn mit dem Support beschäftigt? Gruß David

[@aligarh004]

@@DavidTielke Hi David, An manchen Tagen sind wir den ganzen Tag damit beschäftigt den Support zu leisten. An anderen Tagen 40-50%. Das schlimme dabei ist, dass man immer wieder von der eigentlichen Aufgabe rausgerissen wird.

[@LarsPW]

Ich weiß nicht, ob das Nicht-Auffinden einer Person in einer Datenbanktabelle oder allgemein das Fehlen eines angeforderten Elementes in einem Container überhaupt als Fehler oder Ausnahme betrachtet werden sollte. Der Code des Containers kann doch überhaupt nicht beurteilen, ob ein fehlendes Element gut oder böse ist. Als Fehler würde ich eher den Versuch ansehen, ein ungeeignetes oder unzureichend spezifiziertes Element im Container unterzubringen. "verlier unterwegs keine Informationen [...]" sieht man an den Stacktraces, die Java- oder .NET-Anwendungen gerne herauslassen, wenn es eine Ausnahme gibt, etwa das Versagen eines SQLs.

[@jenseichberg3426]

jeden Sprint (2 Wochen) werden pro Entwickler 1-2 Bug Tickets bearbeitet. Meiner Meinung zuviel

[@DavidTielke]

Hallo Jens, wie viele Entwickler seid Ihr denn? Gruß David

[@jenseichberg3426]

@@DavidTielke 5 Entwickler und ein Projektmanager Somit sind dies leider schon einige Arbeitsstunden für Bugs die dadurch zusammen kommen.

[@DavidTielke]

Hey Jens, unbedingt viel finde ich das nicht, mache das meist eher an der Menge an zeit fest: wie viel Zeit (in %) verbringt ihr denn mit dem Support? Gruß David