Structured exception handling is an excellent way to handle errors, but wouldn't it be nice if you could execute a different branch of code depending on what specific error just happened? It's a pity that there's just no possible way to filter exceptions using the good old fashioned try and catch. Fortunately, Mateusz has a co-worker who invented that wheel for us.

if (something_bad_happens)
        throw new Exception("File is not correct; 88888");

if (something_else_happens)
        throw new Exception("Tag len exceeded; 1337"); 
...

catch (Exception ex)
{
    if (ex.Message.Contains("88888"))
    {
                ...
    }
    else if (ex.Message.Contains("1337"))
    {
            ...
    }      
}

Relational databases were at one time an absolute standard that nearly any developer could be expected to be familiar with. These days, it's still valuable knowledge, but it's less surprising when someone doesn't know more than the basics- there are so many other ways one might persist data, each with their own tradeoffs. But if someone is developer for a contracting firm specializing in data driven applications, you would expect them to have a little more grounding in RDBMSes than the average developer. Well, you would expect that if you thought the contracting firm was actually selling a valuable service, instead of trying to bilk their customers and their contractors and hope nobody notices.

The important things about RDBMSes is that each table represents a relation- a set of fields that are all conceptually related, like "Employee" (with an employee ID, a name, a hire date, etc.) or "SalesListing" (with a product description, a price, etc.), and then those tables can have relationships to other tables- foreign keys that guarantee that if "SalesListing" has a "SalesRep" field on it, that "SalesRep" has a matching entry in the "Employee" table.

While the world has switched to RESTful APIs, the magical power of SOAP-based web-services was that they made code generation easy. Well, easy-ish. Well, easy when it worked right, and then hard the rest of the time. But if it worked, if the WSDL was up to date and sane, you'd get a nice client-side API to invoke methods on the remote server.

Andrew inherited one such client-side C# API. It looked something like this:

Dates and times are way more complicated than we usually think they are, especially when we're talking about historical dates and times. The solution, of course, is to always use someone else's work, whether it's a library or your language's built-ins, never implement date handling yourself.

For a long time, though, Java's date handling left something to be desired. Which is why Sven found this history lesson in his company's code base:

Ah, the joys of stringly typed code. Everything can be turned into a string, so why not treat everything as a string? It certainly worked for Sebastian's co-worker, who also took it to another level:

If GetTrainAtStation(aTrainNo.ToString) Is Nothing Then
    iTheTrainAtStation.Add(String.Format("{0}", aTrainNo.ToString), aTrainAtStationItem)
End If

We like using constants instead of magic numbers. Today, we see an unusual misuse of them. It's unusual because, while it's a set of bad choices, it's not quite a `#define ONE 1` level of silliness.

First, a little background. Benjamin inherited a building automation system. This building automation system was implemented in Microsoft's Visual C++, version 6.0, way back in the 90s. As of the late 2010s, not only was it still in use, it was still pinned to the same compiler version. So not exactly the most modern of applications, but it accomplished the business goals, albeit with a lot of bugs, errors, and mysterious glitches.