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.
Dot Net What Not Posts
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.
Whilst editing a WPF view, the XAML designer claimed it couldn’t display a child user control due to a null reference exception. Looking at the stack trace, I noticed a wonderfully named method…
What seemed like a simple request to enable spell checking in a WPF application turned out to be significantly more work than I expected.
Specifically, applying a custom dictionary everywhere, without having to write wads and wads of duplicate code kept me going for a while.
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.
Just saw this comment on Stack Overflow, and thought it too good not to repost…
A programmer’s wife sends him to the supermarket. She tells him, “Buy a loaf of bread, and if you see some eggs, grab a dozen.”
The programmer later returns with a dozen loaves of bread under his arm
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.
Having finally given up with dasBlog, and decided to join the rest of the world using WordPress, I was left with the painful job of transferring all my old blog posts across. One advantage this gave was the opportunity to re-read some of my old posts, and see how much (or not) my opinions have changed.
One of my older posts was written when I first started learning F#, and was hugely frustrated at the blatant lies told by a lot of the community in an attempt to convince C# developers to use F#. Whilst I was enjoying F#, and felt it had something fresh to offer, I was (and still am) really annoyed at some of the rubbish being written.
Well, it’s now over two years later, and not much has changed.
Not my invention, and not that new, but I’m surprised at how many developers haven’t come across these.
Read about the disappearing Heisenbug, the reliable Bohrbug, the complex Mandelbug, the frustrating Schrödinbug, the disastrous Hindenbug and the elusive Higgs-bugson!
Note: This assumes you have read and understood the fab articles How to turbocharge your Entity Framework queries – Part 1 and Knowing the difference between IEnumerable<T> and IQueryable<T>. If not, please read them first.
It is important to understand where your code is executed when querying with Entity Framework, as this can make a big difference to the time required to execute your queries.
2 Comments