Jaco's team had a problems with making an embedded web server shut down properly. Something about the shutdown process was deadlocking, so one of their "ninja Yoda coders" rockstarred their way to a solution.

private void stopServer() {
	try {
		if (webServer != null) {
			logger.debug("Shutdown webserver");
			// This goes into a dead lock, therefore I've replaced it with
			// some voodoo stuff.
			logger.debug("Get listener field from web server.");
			Field listenerField = WebServer.class.getDeclaredField("listener");
			listenerField.setAccessible(true);
			Thread listener = (Thread) listenerField.get(webServer);
			listenerField.set(webServer, null);
			logger.debug("Interrupt the listener thread.");
			listener.interrupt();
			webServer = null;
			logger.debug("Shutdown webserver complete");
		} else {
			logger.debug("No webserver to shutdown");
		}
	} catch (Exception e) {
		logger.error(LoggerCodes.RPC_SERVER_SHUTDOWN_FAILURE, e, LoggerUtility.parameters("class",
			e.getClass().getSimpleName(), "message", e.getMessage()));
	}
}

Andy has some concerns about future proofing. In this case, he sends us some C# code that's supposed to validate an IP address.

string[] address = StringTools.splitStr(IP, '.');
if (address.length < 4) {
        throw new Exception("Bad IP format : " + IP);           }

Jan wrote some code that set a property, and a few lines later had to write code to read that value- and the compiler complained. Which is what drew his attention to this C# code:

public string ViewNodeFilter
{
        protected get
        {
                if (viewNodeFilter.IsNotValid())
                {
                        return "null";
                }
                return new JavaScriptSerializer().Serialize(viewNodeFilter);
        }
        set { viewNodeFilter = value; }
}

Languages which do type-coercion are generally setting users up for failure. At some point, you'll make some assumption about your inputs, and then type-coercion kicks in and changes what you expect. We see this all the time in JavaScript, and of course, in PHP. PHP booleans, for example, can surprise you: 0 is false, which is a common enough assumption, but so is "0"- the string zero. As are empty arrays.

But what if you wanted more control over it? Peter sends us this PHP he found:

When accepting user input for things like, say, accessing the filesystem, you need to do some validation. Bad or inappropriate characters could lead to surprises that no one is going to like.

So when Christian first spotted this C# method called SanitizePath, he didn't think much of it. But then he looked at the implementation…