I was using firebug to peek into facebook today, and what I saw stunned me. I saw this as a response to one of their a million and one ajax posts

response = {error: 0, errorSummary: "", errorDescription: "No error.", errorIsWarning: false, payload

: [], onload: ["setCookie(\"made_write_conn\", \"1232098415\", 20000);"]};

/* !eval(new String('response = ('+safeResponse+')) */

Now the untrained eye wont see the catch, and the slow mind might take a second to come to speed with it, but the programmer mind in me saw it immediately like this

Error
errorNumber: 0
errorSummary:
errorDescription: No error

Now if that's funny

simply means u will always have an error associated with any response. and in the case where there is no error, rather than return "null", an instance that says "all is well" is created. what's the biggie?

u dont get it? why would you write an API like that. onSuccess retunr success, on error return error.

wtf is an error occured. description of the error, no error.

go to a doctor, he said u are sick. oh doc, whats the nature of my sickeness, he replied

YOU ARE SICK OF "NO SICKENESS" now thats awesome isnt it??

U r 2 busy thinking about semantics while the writer was busy thinking about code reuse. If he was to create a data structure for "Success", it would be way too similar to the "Failure" or "Error" structure. He therefore decided to merge both into one. He could have decided to call the structure "SuccessOrFailure" or "ErrorOrNoError" but the name doesn't make a difference. He understands what he's trying to do, and the name does not affect the structure in any way.

He sure understands I know, and I am sure if another was to manage that code he will sure be looking for success in an error bag!

In your head think of the data structure "Error" as "ErrorReport" (error is different from error report of course, as error report can make sense as "no error") and keep it moving. You are still talking semantics.