The beauty of structured exception handling is that it removes explicit conditional logic from your code. The conditions are still there, of course: a catch statement is essentially saying "if the exception type is X, then do this". But the strict syntax gives the compiler some freedom, and if you're using a language like Java, which favors checked exceptions (where methods declare what kinds of exceptions they might throw), there are all sorts of shortcuts the compiler might take to keep that efficient.

But hey, that's all implicit, and if there's one thing we've learned, "explicit is better than implicit". How can we make exception handling explicit? Well, our Anonymous submitter inherited some Java code which does just that.

Coming from the US, I have a pretty simplistic model of how postcodes work. They’re either 5 or 9 digits, depending on how precise you’re being. I can validate that with a simple regular expression. There’s a lot of detail encoded in that number, including the central sorting facility and city or town I’m in, but I don’t usually care about those details. In any country with some sort of postcode system, while the pattern of the postcode may change, the complexity of it generally caps out pretty quickly. That’s sort of the point.

Maybe Sam’s co-worker didn’t know what regexes were. Maybe they’d read an article talking about how regexes were expensive, and were worried about performance. Maybe they wrote this method as part of a college assignment and added it to their personal snippet library and never thought about it again. Maybe they just hated their co-workers and were planting landmines for them to stumble across. Regardless, this is how they verified a postcode within their locale.

“We’re a dynamic, multi-paradigm organization, and we do most of our new development in a blend of Ruby and Go. We’re not the kind of company that is dogmatic about tools though, we just want to deliver the best product for our customers.”

That’s what Delphia was told in the interview. She didn’t quite grasp why they were mixing those two techs in the first place, but the interview went well, and she took the job. It was then that she discovered that everything she’d been told was technically true.

Rita caught a weird bug. It was weird, in part, because there hadn’t been any code changes in their label printing application for ages. Yet, there was a sudden new bug. Labels were printing with what was obviously unicode garbage. Interestingly, the application definitely supported unicode- there had been a huge effort a few years back to move the C++ code from chars to wchars.

Rita started debugging, and confirmed that when the label text was populated, memory stored correct values. By the time the data was printed, it no longer did. Obviously, there was something wrong with memory management- something was touching the end of the string and throwing off the output. That was an easy enough bug to make in C++, but tracing through 7,000 lines of label printing code to figure out where things got thrown off was more of a chore, especially with the… “friendly” variable naming convention the original developer had used.