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

ClosedSendChannelException still confusing #957

Closed
trathschlag opened this issue Jan 28, 2019 · 2 comments
Closed

ClosedSendChannelException still confusing #957

trathschlag opened this issue Jan 28, 2019 · 2 comments

Comments

@trathschlag
Copy link

#422 solved the issue for actors, but when using launch, the exception is still swallowed:

fun main(args: Array<String>) {
  runBlocking {
        val channel = Channel<Int>().apply { close() }

        launch {
            channel.send(1)
        }.join()

        println("Scope still alive")
    }
}

output:

Scope still alive
@qwwdfsad
Copy link
Collaborator

qwwdfsad commented Jan 30, 2019

It is because the channel is closed with ClosedSendChannelException by default, which is CancellationException and cancellations are not reported.

But you are right, this behaviour is misleading and may lead to subtle bugs, I will investigate possibilities to change this

@trathschlag
Copy link
Author

Thanks in advance! I assume there is a reason why ClosedSendChannelException extends CancellationException?

@qwwdfsad qwwdfsad added this to the 1.3.0 milestone Mar 29, 2019
@qwwdfsad qwwdfsad self-assigned this Apr 18, 2019
elizarov added a commit that referenced this issue Apr 30, 2019
* ReceiveChannel.cancel always closes channel with CancellationException,
  so sending or receiving from a cancelled channel produces the
  corresponding CancellationException.
* Cancelling produce builder has similar effect, but an more specific
  instance of JobCancellationException is created.
* This ensure that produce/consumeEach pair is transparent with respect
  to cancellation and can be used to build "identity" transformation
  of the flow (the corresponding test is added).
* ClosedSendChannelException is now a subclass of IllegalStateException,
  so that trying to send to a channel that was closed normally is
  reported as program error and is not eaten (test is added).

Fixes #957
Fixes #1128
@elizarov elizarov assigned elizarov and unassigned qwwdfsad Apr 30, 2019
elizarov added a commit that referenced this issue Apr 30, 2019
* ReceiveChannel.cancel always closes channel with CancellationException,
  so sending or receiving from a cancelled channel produces the
  corresponding CancellationException.
* Cancelling produce builder has similar effect, but an more specific
  instance of JobCancellationException is created.
* This ensure that produce/consumeEach pair is transparent with respect
  to cancellation and can be used to build "identity" transformation
  of the flow (the corresponding test is added).
* ClosedSendChannelException is now a subclass of IllegalStateException,
  so that trying to send to a channel that was closed normally is
  reported as program error and is not eaten (test is added).

Fixes #957
Fixes #1128
elizarov added a commit that referenced this issue Apr 30, 2019
* ReceiveChannel.cancel always closes channel with CancellationException,
  so sending or receiving from a cancelled channel produces the
  corresponding CancellationException.
* Cancelling produce builder has similar effect, but an more specific
  instance of JobCancellationException is created.
* This ensure that produce/consumeEach pair is transparent with respect
  to cancellation and can be used to build "identity" transformation
  of the flow (the corresponding test is added).
* ClosedSendChannelException is now a subclass of IllegalStateException,
  so that trying to send to a channel that was closed normally is
  reported as program error and is not eaten (test is added).

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

No branches or pull requests

3 participants