5 ms·

> Isn’t it pathetic that so many allegedly-mainstream languages don’t have HTTP libraries that are this natural and idiomatic? That's after 13 SLoC to make a s

by comex 13y ago

> Isn’t it pathetic that so many allegedly-mainstream languages don’t have HTTP libraries that are this natural and idiomatic? That's after 13 SLoC to make a single HTTP request - I like Go, but that seems almost like a parody. It's not that different from other languages, and the error handling makes it look longer, but for something described as "natural and idiomatic" I would expect it to be one function call plus one failure test, not six and three...

cmccabe 13y ago
Experiencing a networking error is different than receiving Status 200 (or any other error status), which is different than getting a media-type different than "application/json". Personally, I don't see what would be gained by combining them all together in a library, except confusion. A lot of libraries do get this wrong and make it difficult to disentangle what is going on. If you feel like golang needs one method to do all the above, feel free to write one and post it to the mailing list... I doubt that it does, but feel free.
- comex 13y ago
  Depends on the use case. I'd say that for many, many cases, all errors should lead to the same result in the application, but with an error-specific informative message. Even if you want to have special handling for errors such as 4xx that might mean something is permanently wrong, getting a 500 is the same as experiencing a network error (except in a client side app where the latter might mean you're not connected to the Internet and should try again, but then you should use yet another API to determine when to connect), and getting a 200 with the wrong content-type has an excellent chance of meaning the same thing as a network error, in the form of a captive portal. To this extent, APIs with many separate error paths that encourage the user to write their own nonstandard error messages are harmful, because they will probably do worse explaining things than with a common method of triage. Of course there are other cases where the difference matters. It just... doesn't seem very "natural and idiomatic" to me, that's all.
throwit1979 13y ago
When people complain about comprehensive error-checking, it makes my blood boil. Checking and handling all possible error conditions is a GOOD thing.
- comex 13y ago
  Only if you have a meaningfully different thing to do for each type of error, see my response to the sibling comment.
- ballard 13y ago
  Yep. Sometimes crashing isn't an option. There are places in network & systems code that have seemingly complicated but darn important many permutations of state that already exist. Sometimes the differentiation between error conditions requires a combination of conditions (i.e., talking to an existing legacy system.) As for single-threaded map, there are at least two necessary behaviors that handle errors very differently: 1. batch all errors/exceptions/etc and return them as an array 2. return on first error
- azth 13y ago
  > Checking and handling all possible error conditions is a GOOD thing. I agree. But Go seems to have taken the most verbose way to achieve that. Pattern matching should have been the way to go if they did not want to use exceptions. Then again, Go does not have functional constructs, and you wouldn't be able to get far with it. Though it still prevents you from ignoring errors, unlike what exists in the language.
cgag 13y ago
Between that and the bit about the good type inference I thought the post was sarcastic until I saw the gripes.

by comex 13y ago

cmccabe 13y ago

Experiencing a networking error is different than receiving Status 200 (or any other error status), which is different than getting a media-type different than "application/json". Personally, I don't see what would be gained by combining them all together in a library, except confusion. A lot of libraries do get this wrong and make it difficult to disentangle what is going on. If you feel like golang needs one method to do all the above, feel free to write one and post it to the mailing list... I doubt that it does, but feel free.

comex 13y ago
Depends on the use case. I'd say that for many, many cases, all errors should lead to the same result in the application, but with an error-specific informative message. Even if you want to have special handling for errors such as 4xx that might mean something is permanently wrong, getting a 500 is the same as experiencing a network error (except in a client side app where the latter might mean you're not connected to the Internet and should try again, but then you should use yet another API to determine when to connect), and getting a 200 with the wrong content-type has an excellent chance of meaning the same thing as a network error, in the form of a captive portal. To this extent, APIs with many separate error paths that encourage the user to write their own nonstandard error messages are harmful, because they will probably do worse explaining things than with a common method of triage. Of course there are other cases where the difference matters. It just... doesn't seem very "natural and idiomatic" to me, that's all.

throwit1979 13y ago

When people complain about comprehensive error-checking, it makes my blood boil. Checking and handling all possible error conditions is a GOOD thing.

comex 13y ago
Only if you have a meaningfully different thing to do for each type of error, see my response to the sibling comment.
ballard 13y ago
Yep. Sometimes crashing isn't an option. There are places in network & systems code that have seemingly complicated but darn important many permutations of state that already exist. Sometimes the differentiation between error conditions requires a combination of conditions (i.e., talking to an existing legacy system.) As for single-threaded map, there are at least two necessary behaviors that handle errors very differently: 1. batch all errors/exceptions/etc and return them as an array 2. return on first error
azth 13y ago
> Checking and handling all possible error conditions is a GOOD thing. I agree. But Go seems to have taken the most verbose way to achieve that. Pattern matching should have been the way to go if they did not want to use exceptions. Then again, Go does not have functional constructs, and you wouldn't be able to get far with it. Though it still prevents you from ignoring errors, unlike what exists in the language.

cgag 13y ago

Between that and the bit about the good type inference I thought the post was sarcastic until I saw the gripes.