Dotan was digging through vendor supplied documentation to understand how to use an API. To his delight, he found a specific function which solved exactly the problem he had, complete with examples of how it was to be used. Fantastic!

He copied one of the examples, and hit compile, and reviewed the list of errors. Mostly, the errors were around “the function you’re calling doesn’t exist”. He went back to the documentation, checked it, went back to the code, didn’t find any mistakes, and scratched his head.

Now, it’s worth noting the route Dotan took to find the function. He navigated there from a different documentation page, which sent him to an anchor in the middle of a larger documentation page- vendorsite.com/docs/product/specific-api#specific-function.

This meant that as the page loaded, his browser scrolled directly down to the specific-function section of the page. Thus, Dotan missed the gigantic banner at the top of the page for that API, which said this:

/! NOTE /! NOTE /! NOTE /! NOTE /! NOTE /! NOTE /! NOTE /!
This doc was written to help flesh out a user API. The features described here are all hypothetical and do not actually exist yet, don’t assume anything you see on this page works in any version
/! NOTE /! NOTE /! NOTE /! NOTE /! NOTE /! NOTE /! NOTE /!

On one hand, I think providing this kind of documentation is invaluable, both to your end users and for your own development team. It’s a great roadmap, a “documentation driven development” process. And I can see that they made an attempt to be extremely clear about it being incomplete and unimplemented- but they didn’t think about how people actually used their documentation site. A banner at the top of the page only works if you read the page from top to bottom, but documentation pages you will frequently skip to specific sections of the page.

But there was a deeper issue with the way this particular approach was executed: while the page announced that one shouldn’t assume anything works, many of the functions on the page did work. Many did not. There was no rhyme or reason, to version information or other indicators to help a developer understand what was and was not actually implemented.

So while the idea of a documentation-oriented roadmap specifying features that are coming is good, the execution here verged into WTF territory. It was a roadmap, but with all the landmarks erased, so you had no idea where you actually were along the length of that road. And the one warning sign that would help you was hidden behind a bush.

Dotan asks: “WTF is that page doing on the official documentation wiki?”

And I’d say, I understand why it’s there, but boy it should have been more clear about what it actually was.

Article created by: Gabija Palšytė

No wedding is complete without something going wrong. Mistakes, big or small, are bound to happen, whether by the spouses-to-be or their guests. Mess-ups by the latter probably sting more, as it’s something that the bride and groom can’t really prevent or control. While some faux pas aren’t that bad and can be easily laughed off, others end up ruining the special day and staying in the memory forever. 

People have shared many such memorable stories over on wedding planner Ruby Straaten’s Instagram post, which we gathered below for you to react to. To find them, all you have to do is scroll down.

Years ago, Brian had a problem: their C# application would crash sometimes. What was difficult to understand was why it was crashing, because it wouldn’t crash in response to a user action, or really, any easily observable action.

The basic flow was that the users used a desktop application. Many operations that the users wanted to perform were time consuming, so the application spun up background tasks to do them, thus allowing the user to do other things within the application. And sometimes, the application would just crash, both when the user hadn’t done anything, and when all background jobs should have been completed.

The way the background task was launched was this:

seeder.RunSeeder();

It didn’t take too much head scratching to realize what was running every time the application crashed: the garbage collector.

RunSeeder returned a Task object, but since Brian’s application treated the task as “fire and forget”, they didn’t worry about the value itself. But C# did- the garbage collector had to clean up that memory.

And this was running under .Net 4.0. This particular version of the .Net framework was a special, quantum realm, at least when it came to tasks. You see, if a Task raises an exception, nothing happens. At least, not right away. No one is notified of the exception unless they inspect the Task object directly. There’s a cat in the box, and no one knows the state of the cat unless they open the box.

The application wasn’t checking the Task result. The cat remained in a superposition of “exception” and “no exception”. But the garbage collector looked at the task. And, in .Net 4.0, Microsoft made a choice about what to do there: when they opened the box and saw an exception (instead of a cat), they chose to crash.

Microsoft’s logic here wasn’t entirely bad; an uncaught exception means something has gone wrong and hasn’t been handled. There’s no way to be certain the application is in a safe state to continue. Treating it akin to undefined behavior and letting the application crash was a pretty sane choice.

The fix for Brian’s team was simple: observe the exception, and choose not to do anything with it. They truly didn’t care- these tasks were fire-and-forget, and failure was acceptable.

seeder.RunSeeder().ContinueWith(t => { var e = t.IsFaulted ? t.Exception : null; }); 

This code merely opens the box and sees if there’s an exception in there. It does nothing with it.

Now, I’d say as a matter of programming practice, Microsoft was right here. Ignoring exceptions blindly is a definite code smell, even for a fire-and-forget task. Writing the tasks in such a way as they catch and handle any exceptions that bubble up is better, as is checking the results.

But I, and Microsoft, were clearly on the outside in this argument. Starting with .Net 4.5 and moving forward, uncaught exceptions in background tasks were no longer considered show-stoppers. Whether there was a cat or an exception in the box, when the garbage collector observed it, it got thrown away either way.

In the end, this reminds me of my own failing using background tasks in .Net.

The first time Z hit the captcha on his company’s site, he didn’t think much of it. And to be honest, the second time he wasn’t paying that much attention. So it wasn’t until the third time that he realized that the captcha had showed him the same image every single time- a “5” with lines scribbled all over it.

That led Z to dig out the source and see how the captcha was implemneted.

<Center>Click a number below to proceed to the next page. <br>Some browsers do not like this feature and will try to get around it. If you are having trouble<br> seeing the image, empty your internet cache and temporary internet files may help. <br>Please ensure you have no refresher add-ons installed on your browser.<br />
<table border=1><Tr><td colspan='3' align='center'>
<font style='font-size:36px;'><img width='150' title='5' alt='5' src='valimages/5.gif'> font>td>tr>
<Tr>
<Td align=center><font size='6'><A href='valid.php?got=crimied&linknum=1'>1a>font>td>
<Td align=center><font size='6'><A href='valid.php?got=crimied&linknum=2'>2a>font>td>
<Td align=center><font size='6'><A href='valid.php?got=crimied&linknum=3'>3a>font>td>
tr>
<Tr>
<Td align=center><font size='6'><A href='valid.php?got=crimied&linknum=4'>4a>font>td>
<Td align=center><font size='6'><A href='valid.php?got=crimied&linknum=5'>5a>font>td>
<Td align=center><font size='6'><A href='valid.php?got=crimied&linknum=6'>6a>font>td>
tr>
<tr>
<Td align=center><font size='6'><A href='valid.php?got=crimied&linknum=7'>7a>font>td>
<Td align=center><font size='6'><A href='valid.php?got=crimied&linknum=8'>8a>font>td>
<Td align=center><font size='6'><A href='valid.php?got=crimied&linknum=9'>9a>font>td>
tr>table>
Center>

Look, I know there’s a joke about how hard it is to center things in CSS, but I think we’ve gone a little overboard with our attempt here.

Now, the PHP driving this page could have easily been implemented to randomly select an image from the valimages directory, and there was some commented out code to that effect. But it appears that whoever wrote it couldn’t quite understand how to link the selected image to the behavior in valid.php, so they just opted to hard code in five as the correct answer.

The bonus, of course, is that the image for five is named 5.gif, which means if anyone really wanted to bypass the captcha, it’d be trivial to do so by scraping the code. I mean, not more trivial than just realizing “it’s the same answer every time”, but still, trivial.

Of course, out here in the real world, captchas have never been about keeping bots out of sites, and instead are just a way to trick the world into training AI. Pretty soon we’ll roll out the Voight-Kampf test, but again, the secret purpose won’t be to find the replicants, but instead gather data so that the next generation of replicants can pass the test.