Kategorien

Weblog Liste

Archiv

Administration

Sign In
 Monday, November 05, 2007
Monday, November 05, 2007 4:55:12 PM (Mitteleuropäische Zeit, UTC+01:00) #
Comments [1]

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!

 Friday, June 29, 2007
Friday, June 29, 2007 2:19:12 PM (Mitteleuropäische Sommerzeit, UTC+02:00) #
Comments [1]

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. :-)
 Friday, March 02, 2007
Friday, March 02, 2007 3:33:31 PM (Mitteleuropäische Zeit, UTC+01:00) #
Comments [1]

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.

 Tuesday, January 09, 2007
Tuesday, January 09, 2007 10:42:38 AM (Mitteleuropäische Zeit, UTC+01:00) #
Comments [1]

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.