Training - Beratung - Projektarbeiten

www.David-Tielke.de

Webcast C# 6.0 – Folge 9: Exception Filters

Das Exceptionshandling in C# ist sehr vielfältig und fast alle Wünsche können mit Try/Catch/Finally abgedeckt werden. Bisher gab es allerdings keine Möglichkeit, wie in anderen Sprachen auf der .NET-Plattform, einen catch-Block nur dann auszuführen, wenn eine bestimmte Bedingung erfüllt ist. So könnte eine von COM fliegende Exception auf den Fehlercode ausgewertet werden, o.ä. Mit C# 6.0 wurde das Exceptionhandling um die Exception Filters erweitert, um solche Szenarien abzudecken.

Dazu aus der Project Roslyn Webseite:

VB has them. F# has them. Now C# has them too. This is what they look like:
try { … }
catch (MyException e) when (myfilter(e))
{
    …
}
If the parenthesized expression evaluates to true, the catch block is run, otherwise the exception keeps going. Exception filters are preferable to catching and rethrowing because they leave the stack unharmed. If the exception later causes the stack to be dumped, you can see where it originally came from, rather than just the last place it was rethrown. It is also a common and accepted form of “abuse” to use exception filters for side effects; e.g. logging. They can inspect an exception “flying by” without intercepting its course. In those cases, the filter will often be a call to a false-returning helper function which executes the side effects:
private static bool Log(Exception e) { /* log it */ ; return false; }
…
try { … } catch (Exception e) when (Log(e)) {}
Links

Webcast C#6.0 – Folge 8: Index Initializer

Manche Erweiterungen der Sprache C# in der Version 6.0 sind überragend und andere eher weniger. Ein Vertreter letzterer Kategorie sind die Index Initializer. Auch wenn ein Dictionary nun ähnlich den Collection Initializern erstellt werden kann, so wird dieser Syntax in der Praxis eher seltener genutzt werden, da Collections die IDictionary implementieren, in den allermeisten Fällen dynamisch mit Werten gefüllt werden.

Dazu von der Project Roslyn Webseite:

Object and collection initializers are useful for declaratively initializing fields and properties of objects, or giving a collection an initial set of elements. Initializing dictionaries and other objects with indexers is less elegant. We are adding a new syntax to object initializers allowing you to set values to keys through any indexer that the new object has:
var numbers = new Dictionary {
    [7] = "seven",
    [9] = "nine",
    [13] = "thirteen"
};
Links

Webcast C# 6.0 - Folge 7: nameof() Operator

Kleine Veränderungen können manchmal großes Bewirken. Auf kaum eine Erweiterung trifft diese Aussage mehr zu, als auf den neuen nameof Operator. Musste man in der Vergangenheit an bestimmten stellen den Namen eines Members einer Klasse oder Methode angeben, z.B. beim Logging oder dem Auslösen einer ArgumentException, so musste dieser Name als string angegeben werden. Wurde der Parameter später während eines Refactorings umbenannt, wurde dies oft beim übergebenen string nicht gemacht. Und so schlichen sich Fehler ein, die weder beim kompilieren noch noch während dem Betrieb aufgefallen sind, sondern an der Stelle, an der man sie am dringendsten Benötigte: Beim debuggen nach Fehlerzuständen. Dies ist nur ein Beispiel, bei dem der neue nameof Operator hilfreich sein kann. Für mich definitiv der heimliche Star von C# 6.0.

Dazu von der Project Roslyn Webseite

Occasionally you need to provide a string that names some program element: when throwing an ArgumentNullException you want to name the guilty argument; when raising a PropertyChanged event you want to name the property that changed, etc. Using string literals for this purpose is simple, but error prone. You may spell it wrong, or a refactoring may leave it stale. nameof expressions are essentially a fancy kind of string literal where the compiler checks that you have something of the given name, and Visual Studio knows what it refers to, so navigation and refactoring will work:
if (x == null) throw new ArgumentNullException(nameof(x));
You can put more elaborate dotted names in a nameof expression, but that’s just to tell the compiler where to look: only the final identifier will be used:
WriteLine(nameof(person.Address.ZipCode)); // prints "ZipCode"

Links: