I agree that exceptions throwing has to be explicitly defined. Anybody would rely on an execution flow interruption that MAY happen. My preference is to NEVER throw exception on 4xx/5xx as those are not exceptional. Those are just valid HTTP responses like any other responses. I know some API that use 409 (Conflict) as a normal execution flow. As an example, the Gitlab API return this one when you try to add a user to a group he already belongs to. As a conclusion, I think the only exception a client can throw are NetworkExceptions as anybody expect the network to fail in his application, so it's an exceptional case.
Le lun. 4 sept. 2017 à 02:13, Sara Golemon <[email protected]> a écrit : > On Friday, August 25, 2017 at 4:10:06 AM UTC-4, Barry vd. Heuvel wrote: >> >> So given the unanimous support for the HTTP Client and the current >> implementations, the only actual point of discussion is the throwing of >> Exceptions on 4xx/5xx responses, right? >> >> As a library maintainer, I'd like to rely on the behavior of the Client, >> so either ALWAYS or NEVER, not depending om some hidden config. Otherwise >> I'd have to check both cases again every time. >> And in that case my preference would be to NOT throw exceptions on >> 4xx/5xx errors. >> >> Hope this will make it to a real PSR soon :) Good job! >> > > Agreed 100% about having an ALWAYS/NEVER decision on exceptions. I differ > on my preference, but I also defer to those maintaining and using http > clients on a regular basis. Jason made the argument that the exception is > on the remote end, but I take the view that the consumer was expecting a > response and didn't get one. That's exceptional. The client gets to decide > how it handles that error whether it's a status code or an exception, so > that half of the argument doesn't hold. By the same token, that also means > that as a consumer, I don't really care what the library does so long as > it's consistent, so I come back to the start: Just define ALWAYS/NEVER and > the rest of us will deal with it from there. > > -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/8cd91c71-0738-4aee-8391-54cff756051b%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/8cd91c71-0738-4aee-8391-54cff756051b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANBrOc0cev28721Q3R%2Bs2x%3D%3DADHvtudQHDr3v09dkhhi%3DW%3DxLw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
