> On Sept. 25, 2015, 10:52 p.m., Ben Mahler wrote:
> > 3rdparty/libprocess/include/process/http.hpp, lines 59-60
> > <https://reviews.apache.org/r/38416/diff/3/?file=1084843#file1084843line59>
> >
> >     How about just status()?
> >     
> >     We can also avoid Option here by just returning the number value with 
> > no message? That seems cleaner?
> 
> Timothy Chen wrote:
>     Not sure how this is useful if it only returns the number value?
> 
> Ben Mahler wrote:
>     Well, you have unconditional gets which can crash the program:
>     
>     ```
>       Response(StatusCode _code)
>         : type(NONE), code(_code)
>       {
>         status = statusString((uint16_t)code).get(); // XXX
>       }
>     
>       explicit Response(
>           const std::string& _body,
>           StatusCode _code)
>         : type(BODY),
>           body(_body),
>           code(_code)
>       {
>         headers["Content-Length"] = stringify(body.size());
>         status = statusString((uint16_t)code).get(); // XXX
>       }
>     ```
>     
>     Also the tests have unconditional gets, which is unfortunate. Rather than 
> updating all the call sites to deal with None, I would suggest following a 
> similar approach to strerror (which always returns a string, if I pass 9999 I 
> get back "Unknown error: 9999".
>     
>     The other reason is that since the strings coming out from this method 
> include the number ("<NUMBER> <REASON>"), a better answer for unknown 
> statuses is to only include the number ("<NUMBER>"), since this is already 
> captures that <REASON> is omitted. Thoughts?

Ah ok I didn't get the default error message part. I think if we're going to 
keep the map and also use it to get status strings, I think I'll keep the old 
behavior where we have statuses map which is statically initialized, and just 
use that to check and get status strings for now. Since we have to check the 
status code in the map anyway to set the response->flag.


- Timothy


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38416/#review100711
-----------------------------------------------------------


On Sept. 25, 2015, 10:38 p.m., Timothy Chen wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38416/
> -----------------------------------------------------------
> 
> (Updated Sept. 25, 2015, 10:38 p.m.)
> 
> 
> Review request for mesos, Anand Mazumdar, Ben Mahler, Jie Yu, Jojy Varghese, 
> and Jiang Yan Xu.
> 
> 
> Bugs: MESOS-3429
>     https://issues.apache.org/jira/browse/MESOS-3429
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Allow HTTP response codes to be checked with code.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp 
> fbd6cf7967173495875a8ea90ed28ade88b982a2 
>   3rdparty/libprocess/src/decoder.hpp 
> 67a5135f302153e376e8dfe8db82aa0b15449389 
>   3rdparty/libprocess/src/http.cpp 9ad613a16c379b6d76a9a0f8d6160fe23a182fd4 
>   3rdparty/libprocess/src/process.cpp 
> 4afa30569b4d235637b49a624602e6b199c32e0e 
>   3rdparty/libprocess/src/tests/benchmarks.cpp 
> 97c81b8e61a75771e5bf7d46505cec4e0c0f404a 
>   3rdparty/libprocess/src/tests/http_tests.cpp 
> d0b9399d38fa284466a012a21080b1d9007af98b 
>   3rdparty/libprocess/src/tests/process_tests.cpp 
> 1023500ac2e3c55be955c4686e7f720eba6b4cc9 
> 
> Diff: https://reviews.apache.org/r/38416/diff/
> 
> 
> Testing
> -------
> 
> make
> 
> 
> Thanks,
> 
> Timothy Chen
> 
>

Reply via email to