Latest posts

Func vs Expression - The LINQ expression node type Invoke is not supported in LINQ to Entities

Func vs Expression - The LINQ expression node type Invoke is not supported in LINQ to Entities

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 better way of handling exceptions

A better way of handling exceptions

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.