Yea, I don’t think this is just a kotlin concept, ...

# codereview

[Zach Klippenstein (he/him) [MOD]]

Yea, I don’t think this is just a kotlin concept, and it’s not new. A lot has been written about the dangers of using exceptions for non-exceptional errors, control flow, etc.

It’s a lot easier to solve when you have a stronger type system like kotlin does. Functional programming has patterns to solve this that have become pretty popular in modern kotlin.

It’s painful to try to adopt if you’re migrating an old codebase, but if you think about this when you’re initially designing and writing code it’s a lot easier.

[thanksforallthefish]

I tried several times, but never really found it comfortable without support for ie arrow. Either is a pretty useful concept, but it still means each node of the chain has to explicitly handle the error case and in practice I find myself most often than not in need to simply forward the error. and when that is the case, exception is more straightforward way

[thanksforallthefish]

I agree that error != exception and I am abusing exceptions, but it just feels like a de facto standard

[Zach Klippenstein (he/him) [MOD]]

I think using goto everywhere was a de facto standard at one point, didn’t make it a good practice 😉

[thanksforallthefish]

goto is still used a lot, you just don’t see it 😉 but I know what you mean and in me I believe you are right, it is a bit of a trade-off in writing more code (because you need to handle errors explicitly) vs having an easier time reading (because everything is spelled out) and usually we all agree reading is more important. don’t know why I don’t feel stronger against exceptions, maybe it is really because I am used to them

[christophsturm]

it probably boils down to what you think is exceptional. but an error reply from a 3rd party api is probably not an exceptional event

[christophsturm]

https://ktor.io/docs/response-validation.html#expect-success

[christophsturm]

I really like the rule of thumb, anything that you don't want to bubble up is not an exception, but a lot of library code that I see does not adhere to that rule

[Michael Böiers]

Wrap it, or look for another library?

[christophsturm]

i was just wondering if thats really apis that people like. because in reality theres probably a lot of people who think its akward

[christophsturm]

and if thats the common consensus here, i just wonder why so many libraries don't do it

[christophsturm]

also I think there should be no things that you have to think about upfront. anything can be refactored to.

[Zach Klippenstein (he/him) [MOD]]

Sure it can be, doesn’t mean it will be easy. And it takes time - you can save a lot of time by designing and writing code upfront that handles at least some of the requirements you know about already.

[Zach Klippenstein (he/him) [MOD]]

Pretty much all of software engineering is trying to figure out how to build things in a better way using things we’ve learned in the past.

[christophsturm]

so in the example of a http client. a 500 reply is definately an exception. some 4xx replies could be exceptions, some could be regular error replies

[Roukanken]

hmm, I do agree that anything that you don't want to bubble up majority of time, is not an exception. If you can't handle the error (not exception) in current method, then your caller should handle it (and therefore you want to just use smth functional to process result, but pass error up by 1)

as for how this impact API design... the problem is, you don't entirely know what library user wants and does not want to bubble up. I guess best solution would be to provide both methods, like stdlib does - eg as was mentioned toInt() and toIntOrNull()

to take example on HTTP client, fetch() , returning sealed class of HttpError responses (so client can choose which to handle with with, and which to bubble up with else branch in it). And second fetchOrThrow() which would simply throw everything, to be used when client simply expect result everytime. (Names to be changed)

or if you think client needs more decision precision than just HTTP codes, then you would have to write some DLS to match them or smth... that sadly wouldn't be that pretty I think.