:mega: Folks, would appreciate your feedback on this! <https://twitter.com/JetBrainsKtor/status/1466...

# ktor

[hhariri]

📣 Folks, would appreciate your feedback on this! https://twitter.com/JetBrainsKtor/status/1466061672481796103 📣

[Trevor Stone]

Can you share insight into the current debate for why some feel it's worth changing?

[Big Chungus]

I'd like to keep exceptions for client calls that are returning extracted and deserialized response body, but not to throw exceptions when returning some abstraction container over http response (with headers, body, response code and other metadata)

[hhariri]

@Trevor Stone we observe a good number of users setting this value to False (i.e. changing the default). This is based on internal usage at JetBrains as well as the occasional code we see in samples, etc. And also a few of us on the team kind of feel like anything outside of 2XX is still a valid status code so shouldn’t be treated as an exception (which is really for exceptional cases).

[Hasan Hosgel (alosdev)]

I always set if to false, because not having 200 is not a runtime error it is an expected one if you use http status codes.

[Big Chungus]

If only kotlin would have a distinction between the two. Almost like it needs "checked" exceptions
🧌

[Big Chungus]

To be clear, I'm not a fan of checked exceptions.

[Peter]

+1 for no exceptions, especially not if the remote server returned a response of any kind
saves me from having to wrap those exceptions myself 😄

[Dominaezzz]

+1 for no exceptions, I always turn them off.

[Javier]

No exceptions, indeed I have adapters for both, retrofit and ktor returning an Either<SomeError, SomeSuccess>

[Javier]

where SomeError is not an exception, is my own error class

[zpearce]

+1 for defaulting to not throwing