In 2014 Jon Kalb 1 gave a three hour presentation at cppcon on how to write exception safe code 234. In the talk, Kalb sets out a series of guidelines on how to write exception safe code. In this post I’m going to go over those guidelines, with a few small adaptations of my own. If you’re interested in using exceptions in your code I highly recommend the talk, as you will find Kalb’s thoughts mirror many of my own on the subject.
Back in 2005 Raymond Chen of Microsoft 1 wrote a piece lamenting exceptions as making a hard problem harder. In this article I want to revisit his thoughts and see how they fit in with what we know 11 years later.
Before I start looking at the drawbacks of exceptions, I want to go over some of the other benefits. To illustrate these benefits I’m going to use a simple function.
In C++ there is one situation where it is only possible to use exceptions to report an error - when object constructors can fail. In exception-free code bases this leads to the additional requirement that constructors must always succeed. For certain design patterns having constructors that always succeed can simplify code - but in this article I want to look at the knock on effect this decision has on the design of the entire system, and how exceptions actually permit a simplified, more coherent design.
In this post I would like to talk about what I consider to be one of the primary benefits for using exceptions to handle errors. That is, I believe that exceptions improve the flow of the code.
One criticism levelled against exceptions is that they negatively impact on performance. In this article I will attempt to address this misconception.
One of the criticisms levelled at C++ is that its large and complex feature set can be difficult to master, and as someone who’s been programming primarily in C++ for over 15 years and is still discovering new and exciting aspects of the language that’s certainly a viewpoint I can relate to.
This post is the TLDR of my On Testing series.
So far in this series I’ve talked about automated testing. Automated testing is an essential part of what makes sprints viable - because in order for something to be releasable it needs to work, and in order to know something works we (usually) have to test it. Thus, everything I’ve written so far is very useful in Agile environments. In this article I want to touch on the place I think manual testing has in these environments.
Behaviour-driven development specifies that tests of any unit of software should be specified in terms of the desired behaviour of the unit. Which is good, because, as we’ve already established testing behaviour is what lets our tests stand the test of time.
In this part of my “On Testing” series I talk about what I believe the goals of automated testing are, and how they influence how you should write tests.
Carrying on the testing theme, in this article I’m going to describe “the test pyramid”. The test pyramid is a way of thinking about how tests relate to one another - and how they support building quality software.
Lately I’ve been thinking about testing, so in this series I want to talk about how I approach testing and some of my personal philosophy. I intend to focus on what I believe it takes to make tests work as part of a robust development process.