What to do with a caught exception

Some people like exceptions and some don't. Some people like them for exceptional things. Regardless of what type you are there is also a debate about what you do with that exception once you catch it.

These are not the abstractions you are looking for

People around me often hear me mumble things like "I think we are missing a level of abstraction here". This is something that often happens when I help people understand how to efficiently unit test a piece of code. But right before Christmas I was working in some code that perfectly highlighted that all abstractions are not equal.

The I have no idea what I'm testing anti-pattern.

It is no secret that I'm not a big fan of service locators in general, but even if you are a fan of those there is a pattern I really don't want to see in unit tests. I will call this the I-have-no-idea-what-I-am-testing-anti-pattern.

2014 statistics

So what did you enjoy in 2014. Here are the truth based on statistics.

A kingdom for a developer

So this happened a few years ago in the days between Christmas and New Year. I was using the slow days after Christmas to get some work done in the office when suddenly a guy from the operations team came running down the hallways shouting "a developer, a developer, a kingdom for a developer"!

Do you really want to properly implement TAP?

There is one part of implementing an API using TAP that I've always found cumbersome and that is the guideline to throw argument exceptions before the task is started. I've always been glad that I never had to make the call since I haven't been developing externally available libraries, but recently I had an interesting discussion at work that made me reevaluate my standpoint. Maybe...

Never hide a TUF in a TUC

This slogan (never hide a TUF in a TUC) was introduced (to me at least) in 2010 by Michael Feathers. Turns out it is a pretty good tool to explain and steer people in the right direction when they are new to writing unit tests. But what is TUF and TUC?

Faking 3rd party dependencies

When it comes to dealing with third party dependencies in my code I've used the same trick for a long time. But I was recently introduced to a new trick that I have mixed feelings about.

The ProducerConsumerStream

I just wanted to let you know that I got a good idea and renamed the NoMemoryStream.

The Good Diagnostics Paradox

If you want your system to have good diagnostics (aka logging) I find there is a kind of catch-22 in achieving it. And that is regardless of if we are thinking about diagnostics in order to understand why things went wrong or if it is to do business analysis. And rather than calling it catch-22 I'll call it a paradox. Because it sounds cooler...