4 ms·
I'd wager 99% of codes have a big if(200) { // Do stuff } else { // Try again later } Actually, a bunch of them probably don't even check for response code. E
by Wilya 13y ago
I'd wager 99% of codes have a big if(200) { // Do stuff } else { // Try again later }
Actually, a bunch of them probably don't even check for response code.
Edit: If dataaccessd is really the iOS native CALDAV integration, that's a bit annoying. Of all people, they should be able to handle that correctly.
- pyre 13y agoif(200) { // Do stuff } else { // Try again later } That's like an "idiot-filter" interview question. "Is the following code valid?"
- jimbobimbo 13y agoThis is a very interesting observation! I imagine, there could be a great conversation derived from this seemingly easy question.
- Groxx 13y agoSeems like it should be paired with a "Is the following code useful?" about code which specifically handles every error code listed here http://en.wikipedia.org/wiki/List_of_HTTP_status_codes http://en.wikipedia.org/wiki/List_of_HTTP_status_codes and contains code to handle unlisted ones. Then "where do you draw the line?". Sometimes if(200){}else{} is plenty.
- pessimizer 13y agoThis is a silly objection. Not every code merits specific handling because there are groups of codes that merit the same handling. if(200){...}else{retry} is never plenty.
- Groxx 13y agoAssume it only queries your server. Assume your server will only ever meaningfully return 200. Assume the method has no reason to ever move (so no 301 redirect (edit: and redirects are generally handled by your request library anyway)). Assume the only time it should fail is if your server falls over on itself, which should be temporary. What else would you do then? These are not crazy expectations. Exponential backoff might be reasonable, but I'd argue that's part of "else{retry}" since it's inherently retrying.
- derefr 13y ago> These are not crazy expectations. Sure they are. Choosing to communicate over HTTP means allowing for the presence of proxies between "your" client and "your" server. In HTTP, you don't control the whole path, even if you control both sides.
- Groxx 13y agoProxies are also fuzzy. I assume you're referring to e.g. a 407 or 511 error? Many times they're handled by something between you and the network library, often the operating system. Sometimes they're not handled at all at the system level (hooray, Android (until recent versions)!), so if you didn't put a proxy in there, you don't have one. VPNs can also exist, but they sometimes send custom error status codes[1]. How do you handle those? Retry if `code % 3 == 1`? Will your program even be informed if the VPN connection is restored, or will you have to just blindly retry until it works? [1]: http://compnetworking.about.com/od/vpnsetup/tp/common-vpn-error-codes-explained.htm http://compnetworking.about.com/od/vpnsetup/tp/common-vpn-er...
- pyre 13y agoI was superficially commenting on the fact that '//' comments everything to the end of the line[1], but as @jimbobimbo pointed out there are multiple layers here, and it would be a good lead-in to a conversation in an interview. [1]: It just struck me as one of those "low bar" technical interview questions.
- Groxx 13y agohaha, that kinda makes me want to make a language that prevents comments from breaking scopes, so "}" would implicitly also be a comment terminator :)
- pyre 13y agoOff the top of my head, Vim has a folding mode where "{{{" and "}}}" are used to mark the start and end of a fold. So you can see this on the code: // ==== Section 1: Code ==== {{{ BLAH // ========================= }}} Granted, since this is Vim-specific, you usually only see it used in Vim plugins, because you're unlikely to have someone editing with another editor.
- dylangs1030 13y ago"What port does ping work over?"
- pyre 13y agoDepends on the position you're hiring for. I imagine a lot of smart people might not know the answer to this because they've never really thought about ICMP or the OSI model.