Forums
Code Snippet Of the Day (CodeSOD) features interesting and usually incorrect code snippets taken from actual production code in a commercial and/or open source software projects.
One of the big pieces of advice about using exceptions and errors is that they shouldn't be used for flow control. You catch an exception when an exceptional event happens, but you don't, for example, throw an exception to break out of a loop.
Unless you're Python, which throws exceptions to break out of loops. That's just how iteration works. But we're not here to talk about Python.
Alex sends us some Objective-C code which… well, let's just say that the code is suspicious looking, but there's nothing clearly bad about it.
Jul 21+(const char*)st:(NSArray*)a a:(int)i
{
@try
{
return ([a objectAtIndex:i]==[NSNull null])?"":[[a objectAtIndex:i]UTF8String];
}
@catch (...)
{
return "";
}
}
Some time ago, Will started a new job- a four month contract to take an old, ugly DOS application and turn it into a new, shiny VisualBasic 6 application. "And," the new boss explained, "the new program is almost done anyway. It's just that the last guy left, so we need someone to take it over the finish line."
A key feature was that it needed to be able to fetch PDF files stored on a shared network drive. The order numbers were serialized, but the PDFs themselves were organized by year, creating file paths like I:\ORDLOG\2007\172.pdf. Now, in this particular block of code, one had access to both the ordnum and the ordyear, so constructing this path could be a trivial exercise. The previous developer did not take the trivial path, though.