Hi Folks, I saw this article by Roman, <https://m...

# announcements

[Dibya Ranjan]

Hi Folks,

I saw this article by Roman, https://medium.com/@elizarov/kotlin-and-exceptions-8062f589d07 I had been a Java developer and started adopting Kotlin few weeks back. Most of my code is very similar in terms of what I would write in Java 11. I am quoting Roman here *As a rule of thumb, you should not be catching exceptions in general Kotlin code.* That's a code smell. .

I see that I can make changes to my APIs to validate and return rather than throwing and catching an exception. However, I failed to come up with a better code for one scenario.

I have a Kafka consumer, which makes a call to a web API. so I have onListen(p: Person) -> orchestrator(p: Persons) -> makeRestCall(p: Person) -> API the exception flow here as I would do in Java is to handle all non response codes 200s. If there is an error returned from the API, I throw and exception, the orchestrator catches it. Is this an anti pattern in Kotlin? I think I am not the first person to have this issue, it would be of great help if someone can give a direction here. Thank you.

[Hanno]

Wouldn't it be possible to first replace exceptions with a result return type? You could encapsulate your non-200-responses as they are not a bug or unexpected behaviour with sth the article does with ParsedDate.

Your orchestrator (i am Not really sure what its purpouse is) then gets a list, flow or whatever of results and can then handle success and failures rather than catching anything

[Dibya Ranjan]

@Hanno - Thank you for the suggestion. I missed one important aspect. I am not expecting the API to return anything. This use case is to make a call to the Create API. For these types of use case when there isn’t a need of returning anything, how can we define alternative flows?

Would it be a good idea to return the Http status code itself? I think we will leak aspect to the caller. For now, the service layer is never aware of what goes inside makeRestCall only thing it is aware of is whether the call was successful or not.

I know my java code style is holding me down on this aspect but I was curious to know how everyone deals with this. Appreciate your help suggestions.

[Hanno]

Ah i c, that's an important restriction though and it exists in a lot of places where libs and frameworks interact. I see two possibilities.

1) it looks like the framework would benefit from allowing a return value of type result, as that is exactly what models success and failure. The signature in the framework can be Result<T>, whereas your concrete implementation can return sth more specific, but the framework doesnt need to be aware of that.

2) you keep exceptions and model unsuccessful results as exceptions with for example your return codes. The framework then has to keep catching everything. Would be a little bit better if the framework provides an exception type that can be subclassed, otherwise it will catch exceptions that are no api call errors

[Hanno]

At my Job, we transitioned to this style completely and it's very nice and satisfying :) one tale though... Even if your service is asked to return a result...exceptions can be thrown freely and on jvm, java, kotlin always will.. the framework should thus always catch those exceptions, this is also mentioned in the article and i can confirm that it really sucks if you don't do that right xD

[Evan R.]

Didn’t the article say that you should have a general exception for network call errors that you catch at the top level of the app? That seems to be what you’re already doing with the orchestrator, so I think you may already be on the right track

[Evan R.]

The article seems to be saying that you should be returning result types if you need to validate the inputs to a function or something

[Brian Dilley]

I prefer exceptions over the functional return types personally. What’s code smell to one man is a flower garden to another IMO. What they’re advocating for is a more Rust type approach to error handling. That is, everything returns some sort of Result object that can be returned all the way up a stack of functions returning a Result type object until someone up the chain decides to handle the error…. sounds a lot like Exceptions to me, except that with Exceptions you don’t have all of the container types for return values.

[Hanno]

@Brian Dilley it's rather not about opinions, but advantages and disadvantages. An undeclared exception that can come out of a method is clearly worse than Something that is declared in the signature - be it as a return type or a checked exception - and can be forced to be handled. Results also don't behave like exceptions, because they don't bubble up the stack implicitly, but have to be returned explicitly somehow by the direct caller.

[Brian Dilley]

Sometimes I don’t want to handle them though, I just want it to bubble up to the root exception handler.

[Hanno]

OK, but that seems to align with the article and all, that's what exceptions are good for. Now it's all about what kind of things you want to bubble up, the article shows a clear recommendation regarding that.

[Dibya Ranjan]

Didn’t the article say that you should have a general exception for network call errors that you catch at the top level of the app?

@Evan R., My understanding was slightly different. My assumption was there has to be top level exception handler around onListen .

I think the way I have coded is not that bad.