One of the least-heralded new features in C# 7 is also one of my favorite: throw expressions. With this feature, you can now use a throw clause in a number of places where you couldn’t previously. Like many of the recent C# changes, this won’t revolutionize your coding by any means, but it will consistently make things a little bit cleaner and more concise. Here are a few of my favorite new ways to throw exceptions.
Recently, a user reported some difficulty using our software. Investigating our error logs, we determined that the culprit was a classic one: SQLServer deadlocks. What made less sense were the two deadlocking queries: one query was an insert into two tables (one via trigger). The other query was a read which joined those same two tables. While there are various ways that this can cause a problem, it shouldn’t have been a persistant issue here and hadn’t ever been one in the past. What was going on?
As developers, most of us are inducted into the cult of common code and Don’t Repeat Yourself (DRY) early on in our software engineering educations and careers. This was certainly the case for me. The idea sticks with us because it just makes so much sense: why write more code when you could write less? Why slog through making changes in dozens of places when you could have updated a single bit of centralized logic? Why re-invent the wheel when you can use a battle-tested implementation that already exists?
Over time, however, I’ve come to see cracks in this philosophy, or at least the absolutist version of it. DRY is a powerful software engineering principle, but it is not the only software engineering principle. As codebases and teams get larger, a religious adherence to DRY can be crippling to maintainability and development time.
On the surface, .NET’s Random class seems comparable to the random number APIs in other frameworks. However, it has a number of quirks that can make it tricky to use correctly. With randomness, bugs can manifest quite subtley: rather than an exception you might just end up slightly biased load balancing or a playlist shuffle that picks the same song first more often than not. Therefore, it’s worth taking the time to make sure you know what you’re doing! This post covers the basic usage patterns for the random class, as well as the gotchas and how the MedallionRandom NuGet Package can help fill in the gaps.
This post walks through bootstrapping an angular app asynchronously. You may find yourself needing to bootstrap angular asynchronously if you need to load system wide configs for example.
When you think of traversing a tree, what comes to mind? Recursion? Looping with a stack? While both of these methods work perfectly well, neither has the elegance, convenience, composability, and laziness of IEnumerable-based traversal using LINQ. Luckily, it isn’t hard to “factor out” the mechanics of traversing trees and tree-like data structures such that we can cleanly process such objects with LINQ without writing lots of boilerplate code first. In this post we’ll look at a couple functions in the MedallionCollections NuGet package that do just that.
Developers love utility functions, and every developer seems to have his or her favorite set. In my various projects, I find myself using the same utilities over and over again, copying them from project to project. This gets frustrating and wastes time, especially when I find a bug or performance issue in a utility and want to get it updated everywhere. The obvious solution is to wrap my favorite utilities up in their own NuGet package, but this has several disadvantages which I’ll describe further on. To address this issue, I’ve created a tool which allows for the creation of “inline” NuGet packages which are, in my mind, a particularly appropriate way to distribute utilities.