Part 4 in my ongoing series of how I implemented the code from Mazes For Programmers by Jamis Buck in C#.
In this post, I explain how I implemented the first two maze-generation algorithms in C#, and show how parts of the code were improved by using Linq.
One of our main applications involves interacting with a third-party API. Whilst this is generally stable, we have had cases recently where it was throwing random exceptions. We could make the same request with the same parameters multiple times, and sometimes it would work, and sometimes it wouldn’t.
While we left the owners of the third-party API scratching their heads, we realised that the way we handled interaction with such APIs wasn’t robust enough. The first (and most obvious) improvement would simply be to try again.
As this is the sort of thing we’d want to do in a number of places, rather than repeat the same boilerplate code over and over again, we looked for a helper class.
We had a situation in which application users were not checking the customer list before adding new customers, which was resulting in multiple entries for the same customer. We wanted to make it so that when they tried to add a new customer, they would be shown a list of possible duplicates.
It turned out that finding duplicates wasn’t as easy as I thought. I ended up with a helper class that used Metaphones to find similar customers. This post describes the class, and shows how to use it.
I was working with a third-party API, and had to specify a date range object, with a start and date. The problem was, their server was throwing intermittent exceptions when I passed this date filter object as a parameter, claiming that the start date was after the end date. I checked the data, and I was definitely sending a valid date range.
The answer to the problem turned out to involve a little-known (to me at least) part of DateTime. Not the sort of thing you encounter every day, but worth knowing about for the times when it hits you.
I had an odd problem, the resolution of which exposed an interesting bit of information about what goes on under the C# covers that we never usually know.
I had a Linq query that worked fine on its own, but failed at run time when I extracted it into a method and passed in a lambda.
Whilst trying to work out why this was happening, I came to an understanding of the difference between a Func and an Expression, and why it (sometimes) matters.
A quick and simple way to find out which method called the current one.
I discovered a gem of a class hidden away in the .NET framework that makes parsing CSV files very simple.
Read more for details, and some sample code.
Like most of us, my applications usually have a global unhandled exception handler, in order that the inevitable unhandled exception won’t crash the system.
The problem with this is that by the time you get to the exception handler, you’ve completely lost the context of what was happening. You’re in an isolated, global context, away from any window.
What you really want is to get immediate feedback when there’s been a problem, so you can react appropriately for the situation. For example, failure to load a customer list could be handled by trying again, up to a maximum number of attempts, before informing the user that the list couldn’t be loaded. By contrast, if they were trying to save an individual customer (presumably from a customer details window), you’d react differently.
Around a year ago, whilst contemplating this issue, I had an idea that turned out to be an excellent answer to the problem. It turned out that this wasn’t an original idea (it was too obvious for that), but as I hadn’t come across it before, I didn’t know that at the time.
In this post, I describe the Fallible type, and how it can be used (really easily) to simplify and improve your exception handling.
As part of some overall auditing in one of my projects, we recently added a LastUpdatedByUserID column to all of the major tables. As the name implies, this column stores the ID of the user who last updated the row. In order to keep an audit trail of the changes, for each table in the database, we have a corresponding TableName_Audit table that is updated (by triggers on the main table) every time the main table is modified.
I noticed that for one of the tables that had had the LastUpdatedByUserID column added, the script to regenerate the audit table hadn’t been run, so the audit table was missing the LastUpdatedByUserID column. This would entirely nullify the point of the column.
This led me to wonder if there were any other tables in the same state. rather than check this manually, I decided to write a script to do it, as this would be useful for future tables. Being a Linq type of person (I rarely write SQL any more), I decided to see if I could do this in LinqPad.
It took a bit of fiddling, but the end result was what I wanted, and paved the way for future queries.
A while back I blogged about a situation where thinking out of the box helped me write some code more quickly. In a nutshell, I needed to extract an exchange rate from an XML feed, and found that by using F# to do it, then translating the code back to C#, it was much easier than trying to write the code in C# in the first place.
I thought it might be interesting to revisit this in both languages, and compare the two experiences. I found this to be a significantly better sales pitch for F# than anything else I’ve seen.
Leave a Comment