Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception handling and transport of exceptions #213

Open
joseffilzmaier opened this issue Oct 2, 2024 · 3 comments
Open

Exception handling and transport of exceptions #213

joseffilzmaier opened this issue Oct 2, 2024 · 3 comments

Comments

@joseffilzmaier
Copy link

Hey there, thank you for the library, it's looking really neat!

Client target: Android
Server target: JVM

I am using the default RPC implementation (i think it's called kRPC) and have have a few remarks/questions regarding exceptions/error handling:
Right now, if i make a request from the client and the server throws an exception, the whole whole exception, stacktrace inclusive, is being transferred to the client.

I have a few issues with this approach:

  • I would like to not send the whole stack trace if an exception occurs. Is there any way currently or planned so that i can customize what happens in case of an exception?
  • The exception handling client side does not work as expected on my end: If i wrap the suspending function call with a try/catch i cannot catch it - It still crashes my whole app. I am currently not sure where the exception is thrown, but i believe it to be in some kind of background coroutine that has no Exception Handler set. It would be nice if i would simply be able to catch the exception client side somehow.

Are there any plans on improving remote exception handling, or am i missing some information here?

@Mr3zee
Copy link
Collaborator

Mr3zee commented Oct 3, 2024

Hey! Thank you for the feedback! We are working on the improved exception handling and we'll take this into account!

@Rattlyy
Copy link

Rattlyy commented Oct 17, 2024

I suggest you try using runCatching {} and return Result<> classes instead

@lsafer-meemer
Copy link

I suggest you try using runCatching {} and return Result<> classes instead

Are Result classes serializable? and if so, how could we guarantee that the class of the exception thrown exists at the client?

The true solution for this issue would either be "either" from arrow-kt with the EitherSerializer added to the serializers module:

val CustomSerializersModule = SerializersModule {
    contextual(Either::class) { (leftSerializer, rightSerializer) ->
        EitherSerializer(leftSerializer, rightSerializer)
    }
}

Or union types when they come someday: https://youtrack.jetbrains.com/issue/KT-68296/Union-Types-for-Errors

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants