3 ms·

if !strings.HasPrefix(mediaType, "application/json") { // bogus media type, deal return HttpErr{Err: errors.New(""), Status: http.StatusUnsup

if !strings.HasPrefix(mediaType, "application/json") { // bogus media type, deal return HttpErr{Err: errors.New(""), Status: http.StatusUnsupportedMediaType} } Sorry, but having dealt with a HTTP library in PHP that did something similar, I would have to hunt you down and kill you. The HTTP response status code from the original request was NOT 415 Unsupported Media Type. Do you have any idea how misleading this error is to the developer? The error you SHOULD be returning is an Application error code "Unexpected Media Type", NOT a HTTP error code. It's the application that has a problem with the returned media type.

buro9 13y ago
> I would have to hunt you down and kill you Attempts at off-the-cuff witty death threats don't tend to work too well online. I truly hope you were jesting.
- jacques_chester 13y ago
  Off-the-cuff witty death threats are a long-standing tradition of internet debate amongst programmers. Not for nothing do we repeat the unknown wit who observed that one should: Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
- jalfresi 13y ago
  Apologies, yes it was an attempt at humor. I was hoping for more of a discussion on the two approaches though if your still game.
  - buro9 13y ago
    Sure. My scenario is a web service, that calls other web services. It throws an error and then has to return something meaningful to the callee, which is usually both a message that tells the developer calling the web service how to fix it (if it's something that they can fix) as well as the relevant response code. The advantage from assigning the code at the earliest point the error is detected is that one avoids any later text parsing of the error message to figure out the right code to return. It also allows general switching on the error code range to see whether you really need to throw the error or whether there is some other branch of logic that could be done instead.

buro9 13y ago

> I would have to hunt you down and kill you Attempts at off-the-cuff witty death threats don't tend to work too well online. I truly hope you were jesting.

jacques_chester 13y ago
Off-the-cuff witty death threats are a long-standing tradition of internet debate amongst programmers. Not for nothing do we repeat the unknown wit who observed that one should: Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
jalfresi 13y ago
Apologies, yes it was an attempt at humor. I was hoping for more of a discussion on the two approaches though if your still game.
- buro9 13y ago
  Sure. My scenario is a web service, that calls other web services. It throws an error and then has to return something meaningful to the callee, which is usually both a message that tells the developer calling the web service how to fix it (if it's something that they can fix) as well as the relevant response code. The advantage from assigning the code at the earliest point the error is detected is that one avoids any later text parsing of the error message to figure out the right code to return. It also allows general switching on the error code range to see whether you really need to throw the error or whether there is some other branch of logic that could be done instead.