Wilko Waitz - Softwareentwicklung

Versionsverwaltung und deren praktischer Einsatz

Wilko Waitz — Mon, 05 Nov 2007 16:55:12 GMT

Versionsverwaltungen sind schon eine nette Sache. Insbesondere für mich, da ich zuweilen an drei unterschiedlichen Rechnern entwickle. Auf diese Art und Weise habe ich immer und überall den aktuellen Entwicklungsstand. Dumm nur, wenn man vergisst am Ende des Tages seine Arbeitsergebnisse einzuchecken. Dann ist obiger Ansatz blanke Theorie. So geschehen am Wochenende.

Jetzt sitze ich hier, mehr als 600 km vom aktuellen Entwicklungsstand entfernt und könnte in die Tischkante beisen. Ich stehe vor der Wahl:

meinen Angehörigen am Telefon zu erläutern, wie sie die Arbeitsergebnisse in die Versionsverwaltung bekommen oder
erläutern wie man in der Firewall den Port für eine Remotedesktopsitzung öffnet
die Arbeit doppelt zu machen.

Egal welche Alternative ich wähle, es kostet mich Zeit und Nerven. Ich werde in der Zukunft wieder auf das Tupel; externe Festplatte und Versionsverwaltung umsteigen. Es könnte nur sein, das ich die Festplatte desöfteren vergesse. Aber davon hört ihr zu gegebener Zeit. Nun noch den Merksatz, damit er sich einprägt und ich vor solchen Unannehmlichkeiten in Zukunft verschont bleibe.

Merksatz 3.0
Am Ende des Arbeitstages sind die Arbeitsergebnisse einzuchecken!

Pocket Blogger

Wilko Waitz — Fri, 29 Jun 2007 14:19:12 GMT

Dies ist der erste Eintrag mit dem Programm 'Pocket Blogger' für WM5 und es stellt meine ersten Gehversuche mit .NET Compact-Framework dar.

Sollte dieses Programm einmal einen Release-Status erreichen, stelle ich es zum Download bereit.

Ein paar Gedanken zur Ausnahmebehandlung

Wilko Waitz — Fri, 02 Mar 2007 15:33:31 GMT

Warum dieser Beitrag

Exceptionhandling ist zum Teil eine Frage der Philosophie und der Einstellung. Einige behandeln Ausnahmen überhaupt nicht und andere Verfahren nach der catch all Philosophie. Beides ist suboptimal.

Wie sieht vernünftige Ausnahmebehandlung aus

Grundsätzlich verfahre ich immer nach folgendenden Merksätzen:

Merksatz 2.0
Behandle nur Ausnahmen, welche du auch lösen kannst.

Dieses Verfahren gaukelt dem Benutzer einer Bibliothek nicht vor, dass sie sich im Normbereich bewegt. Weiterhin kann er für seinen Anwendungsfall geeignete Lösungsstrategien implementieren. Handelt es sich nicht um eine Bibliothek, sondern um das eigentliche Programm, erleichtert es das Testen und das Ermitteln von Grenzbereichen, welches dann wiederrum die Ableitung von geeigneten Lösungsstrategien ermöglicht. Sowohl für die Bibliotheken als auch für die Anwendung.

Merksatz 2.1
Ausnahmen sind bei der Entwicklung eines Produktes notwendig und willkommen. Sie verbessern die Qualität des Produktes, wenn sie frühzeitig auftreten können/dürfen.

Macht eine Anwendung von Log-Mechanismen Gebrauch, so ist nichts dagegen einzuwenden, wenn Codeblöcke existieren, welche der catch all Philosophie folgen, um die Ausnahme zu protokollieren. Wichtig ist nur, dass der Fehler an übergeordnete Schichten weitergeleitet wird. Hierzu ein Beispiel:

try


{

...

}

catch(
... )

{

...

}

catch(
Exception ex )

{

log.Error("Unbehandelte
Ausnahme", ex );

throw;

}

Im konkreten Beispiel wurde log4net verwendet. Wichtig für das Thema ist jedoch, das der rethrow-Mechanismus von .NET verwendet wird.

Wann sollen eigene Ausnahmen erzeugt werden

Eigene Ausnahmen sind sinnvoll, wenn diese ausserhalb eines Exception-Blocks geworfen werden. Sie testen beispielsweise ob die Parameter eines Methodenaufrufs innerhalb eines gültigen Wertebereiches liegen. Dann können und sollten Sie bibliotheks- und programmspezifische Ausnahmen werfen. Gern darf hier von vorhandenen Exceptions abgeleitet werden. Im konkreten Fall und unter .NET von einer ArgumentException.

Das Erzeugen einer eigenen Ausnahme innerhalb eines Exceptionblocks sollte wohl überlegt sein. Es erzeugt auf seiten des Nutzers zusätzlichen Aufwand, auslesen der InnerException, und macht somit den Grund der Ausnahme nicht vollends klar. Es ermutigt den Entwickler, die Programmsteuerung auf Basis von Ausnahmen vorzunehmen.

Sollte man sich dennoch für eigene Exceptiontypen innerhalb eines Exceptionblocks entscheiden, so muß unbedingt die eigentliche Exception, als InnerException, weitergeleitet werden. Andernfalls kann eine Fehlersuche sehr aufwändig werden.

Fazit

Die Ausnahmebehandlung ist ein wichtiger Bestandteil der Softwareentwicklung. Es bietet sich an, zu Beginn des Entwicklungsprozesses, nur wenige Ausnahmen zu behandeln. Im Verlauf der Entwicklung, durch Testen, werden die Gründe für Fehler klarer und können effektiver behandelt werden. Das Verstecken von Fehlverhalten nützt niemanden etwas, sondern führt zu nicht nachvollziehbaren Programmverhalten. Im schlechtesten Fall nach der Auslieferung eines Produktes.

Portal für Softwareentwicklung

Wilko Waitz — Tue, 09 Jan 2007 10:42:38 GMT

Karsten Samaschke ruft mit dem Portal ASPXperts eine Community ins Leben, welche sich u.a. mit den Themen ASP.NET, XML und XML-Webdienste beschäftigt. Ein Bereich, welcher mich persönlich sehr interessiert, ist die Software-Architektur.

Es wird immer wichtiger, seinen Projekten eine strukturierte und durchdachte Architektur zu Grunde zu legen. Häufige Anforderungsänderungen können in Projekten ohne klar definierte Architektur schnell zu Chaos führen. Deshalb fällt es mir sehr positiv auf, dass ASPXperts diesem Thema einen eigenen Bereich spendiert.

Erwartungsgemäß sind derzeit wenige Inhalte zu finden, das Projekt befindet sich in der Enstehungsphase. Mit der Zeit werden sicher interessante und lehrreiche Beiträge aufschlagen.

Ich für meinen Teil habe mich heute registriert.