debugging a very perplexing error that has been dogging this code base for a long time ...that's odd... ...aren't we even CHECKING the return status of this func-pic.twitter.com/nvyG7NR6vG
-
-
3/ been asked some questions about this, so will explain more: * there is only one engineer on this project. it me. * my code uses API entry point 1 to push a large block of data to partner, then uses entry pt 2 to push diffs * counterparty has been acting as if >
Show this thread -
4/ they got the original big block of data, but none of the small diffs. "That's odd", I say, "because right here in my database I have records of having pushed them to you, and every one has a 'success' status code attached". So ... uh uh oh
Show this thread -
5/ I had two (2.5 ?) bugs: * 2nd API call was failing bc I was handing it poorly formatted data ; it returned { :success => false, :error_msg=> "... "} * I failed to check that return code * default value for db column "success?" was true sigh
Show this thread
End of conversation
New conversation -
-
-
Drive-by question, if you don’t mind: Was the documentation for the function whose status code needs to be checked explicitly indicating that this was the case, but it’s one of those functions whose docs one would never bother reading?
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
This is the error class that made James Gosling decide exceptions were a better solution. But then Rob Pike came along and reversed him, so we're back to square one.
-
I like static languages' possible-error return types -- you don't risk random crashes on an unchecked exception case, but the compiler won't let you forget to check the value
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.