Error Handling Part 1: Grundlagen bei der Fehlerbehandlung

In letzter Zeit wurde ich immer wieder gebeten etwas über Fehlerbehandlung zu schreiben. Da das Thema komplex und sehr umfangreich ist habe ich mich immer wieder darum gedrückt. Man sieht aber in der Praxis leider doch, dass es immer wieder Probleme damit gibt. Deshalb habe ich mich jetzt endlich aufgerafft das Thema anzugehen. Da das Thema zu Komplex für einen einzelnen Beitrag ist, werde ich das Ganze als Serie aufbauen: Grundlagen der Fehlerbehandlung Eigene Ausnahamen werfen Guidelines nach David Abrahams Fehlerbehandlung auf Anwendungsebene Beim Verwenden einer Try-Catch-Anweisung kann man wirklich viel falsch machen. Viel mehr als einem meistens bewusst ist. … Continue reading Error Handling Part 1: Grundlagen bei der Fehlerbehandlung

Error Handling Part 2: Eigene Ausnahmen werfen

Hier ist der zweite Parte der Serie über Fehlerbehandlung: Grundlagen der Fehlerbehandlung Eigene Ausnahamen werfen Guidelines nach David Abrahams Fehlerbehandlung auf Anwendungsebene Diesmal geht es darum wann und wie Ausnahmen generiert werden sollen. Generell gilt: Ausnahmen sollten immer dann geworfen werden, wenn die Anwendung oder das Objekt sonst in einen undefinierten Zustand gerät. Ausnahmen sollen kein Teil des normalen Programmflusses sein. Ein gutes Beispiel wie es NICHT geht liefert uns mal wieder SharePoint: Wenn ich auf ein Objekt in eine Auflistung zugreifen will, das nicht existiert werde ich mit einer ArgumentException oder eine SPException überrascht. Dies führt zu folgenden Funktionen, … Continue reading Error Handling Part 2: Eigene Ausnahmen werfen

System.Object.ToString()

Die ToString() Methode ist eine der am meisten verwendeten Funktionen im .Net Framework. Sie ist die einzige Methode die von System.Object implementiert wird und deshalb bei jedem Objekt verfügbar ist – ganz egal von welchem Typ. Die ToString()-Methode erlaubt die Repräsentation eines Objektes als String. Wird sie nicht angegeben, muss jeder Benutzer der Klasse immer selber entscheiden (und entwickeln), wie die Klasse dargestellt wird. Besonders beim Databinding ist das ein immer wiederkehrender Task. Es sollte also immer ein sinnvoller “override” gemacht werden, der eine sinnvolle Darstellung des Objektes als string zurück-gibt. Im einfachsten Fall sieht die Implementierung einfach so aus: … Continue reading System.Object.ToString()

Boxing and Unboxing

Welche Variante gefällt Ihnen besser: Instinktiv werden die meisten erst einmal Variante a bevorzugen. 10.ToString() sieht einfach komisch aus. Dafür gibt es auch noch nicht einmal Unterstützung durch IntelliSense. Aber schauen wir uns mal Variante A genauer an: Die Zahlen sind Integer-Werte (und Integer-Werte sind Value-Typen!). Die Methode Console.WriteLine() hat aber keine Überladung, die Integer-Werte übernimmt. Sie übernimmt nur Paramter vom Typ System.Object. Wenn ein Wertetyp als Object verwendet wird, stellt der JIT-Compiler auf dem Heap eine Box in die eine Kopie des Objektes gelegt wird. Jeder Zugriff auf das Objekt erfolgt über eine Kopie aus der “Box”. Dieser Prozess … Continue reading Boxing and Unboxing

#if/#endif vs. ConditionalAttribut

Mit #if und #endif erstellter Code, der von der Build-Konfiguration anhängt, gilt in C# als schlechte Praxis. Es führt in den meisten Fällen zu schlecht les- und wartbarem Code. Außerdem können sich schnell Bugs einschleichen, die extrem schwer zu finden sind. Der folgende Code veranschaulicht, wie so etwas zum Beispiel passieren kann: Wenn jetzt aber doch eine abhängige Konfiguration benötigt wird? Ein typisches Beispiel ist Trace. Das .NET Framework hat dafür das ConditionalAttribut. Das Attribut wird z.B. von den Trace- und Debug-Klassen im System.Diagnostics-Namensraum verwendet. Das Attribut muss auf einer Funktion vom Typ void angebracht sein: Der große Vorteil ist, … Continue reading #if/#endif vs. ConditionalAttribut

Cast vs. As/Is-Operator

C# ist ja eine stark typisierte Sprache (von dynamic in C# 4.0 abgesehen). Mit den “Generics” wurde der Bedarf der Typumwandlung auch sehr reduziert. Trotzdem gibt es immer wieder die Situation, in der man ein Objekt umwandeln muss. Zum Beispiel bei der Verwendung von Hashtables. In diesem Fall hat man 2 Möglichkeiten: Verwendung des AS-Operators Verwendung von Cast Ich denke es ist offensichtlich, dass die erste Variante übersichtlicher und damit wartbarer ist. Außerdem hat sie einen Geschwindigkeitsvorteil, wenn das Objekt nicht von dem entsprechenden Typ ist, da keine Exception geworfen wird. Wichtig ist, dass nicht erst mit IS geprüft wird, … Continue reading Cast vs. As/Is-Operator

Konstante Werte (const vs. readonly)

In c# kann man konstante Werte auf 2 Arten definieren: Mit dem Schlüsselwort const oder als static readonly. Mit const werden Werte zur Kompilierungszeit definiert (compile time constants). Als static readonly definierte Konstanten sind Laufzeitkonstanten (runtime constants). Wann soll man jetzt welche Variante verwenden? Die Konstante wird bei der Kompilierung als Wert übersetzt. Die Zeile kompiliert also in IL (ungefähr) zu Dies hat natürlich zur Folge, dass alle Clients einer Anwendung neu kompiliert werden müssen, wenn sich eine Konstante ändert. Bzw. kann es zu merkwürdigem Verhalten kommen, wenn sich ein konstanter Wert ändert und eine abhängige Assembly in einer alten … Continue reading Konstante Werte (const vs. readonly)

Modeling Requirements and Software Architecture in Visual Studio 2010

Introduction Some people think that if you do agile software development you do not need to model your application and write UML and architecture documentation. This is not true. You even have to do more of it – you only do it at a different time. You do not do all the modeling beforehand and then build your application – you always design a little and, subsequently, develop a little. If you have several people involved in different projects, it is even more important that you have a consistent way to model and document your requirements and software architecture. Using … Continue reading Modeling Requirements and Software Architecture in Visual Studio 2010

Sandboxed Solutions und PropertyBags

In einer Sandboxed Solution den PropertyBag im Code zu setzen ist eine echte Herausforderung. Folgendes gibt es zu beachten: Properties steht nicht zur Verfügung. Nur AllProperties Wer AllProperties direkt setzt wird erstaunt sein, das die Änderungen einfach Still geschluckt werden Änderungen sind nur über die neuen Methoden SPWeb.AddProperty und SPWeb.SetProperty möglich Auch wenn die Methoden ein Object übernehmen darf man nur string werte übergeben. Sonst bekommt man eine NullReferenceException Continue reading Sandboxed Solutions und PropertyBags