Recently we purchased a watch; a purple affair with butterflies to be exact. Didn’t cost much, and we expected it to be perfectly functional until the battery ran out. As it turns out, after a day, we found out that if you press the dial knob in, the watch stops. It was a reputable high street retailer so you’d think the situation would have been quite easy to rectify.

For a number of reasons (some historical, some legacy, some just daft), the optional Interlok components live in various git providers. This isn’t a post that argues that git flow is great; it’s well understood so we use it to remove the friction of understanding a bespoke tagging/branching system. When we do a product release there’s a Jenkins pipeline that builds all the artefacts based on the release branch from git flow release. That means that when we decide that it’s time to prepare for a release, we have to do a git release start on every project and publish that branch; all of which is nice and scriptable.

One of the things that Vagrant (in Hyper-V mode) does if you sync folders with your linux machine is to attempt to mount them via SMB. This can lead to a few problems; you can work through them, but it’s always easier to cut and paste from someone else’s pain right?

Let’s suppose that you have an Interlok instance servicing HTTP requests and the data being transferred around is JSON messages. In the event that an exception happens what would normally happen is an exception is printed in the log file and a HTTP 500 error returned back to the client. What if we want to send more information such as the stack trace back to the caller as a JSON message.

If you search for the phrase “exceptions as flow control” then most of the top hits are about how bad it is and how you shouldn’t. I don’t disagree with that point, exceptions should be unexpected, so you shouldn’t really be treating them as an expectation. Put it another way, exceptions are, in essence, GOTO statements; everyone knows that GOTOs are bad.