Create UnsafeNonFatal for use in the fiber runtime

[kapunga]

Creates a custom NonFatal type for use in the fiber runtime. This is needed because while application code generally shouldn't catch InterruptedException, the fiber runtime is responsible for dealing with interrupts gracefully.

Initially I considered naming this RuntimeNonFatal, however I think UnsafeNonFatal makes it really clear that you shouldn't use it without knowing what you are doing.

Will resolve #4254

[armanbilge]

Thanks for the PR!! Sorry, would you mind re-targeting to the series/3.6.x branch so we can get it into the 3.6.0 release? 🙏

[kapunga]

Thanks for the PR!! Sorry, would you mind re-targeting to the series/3.6.x branch so we can get it into the 3.6.0 release? 🙏

Done.

[kapunga]

Note, there is a reference to NonFatal in cats.effect.std.SecureRandomCompanionPlatform and another in cats.effect.kernel.testkit.TestContext that can't access UnsafeNonFatal.

[durban]

Note, there is a reference to NonFatal in cats.effect.std.SecureRandomCompanionPlatform and another in cats.effect.kernel.testkit.TestContext that can't access UnsafeNonFatal.

Why can't they access it?

[armanbilge]

Why can't they access it?

Because UnsafeNonFatal is in core, and those modules don't depend on core.

[CJSmith-0141]

Note, there is a reference to NonFatal in cats.effect.std.SecureRandomCompanionPlatform and another in cats.effect.kernel.testkit.TestContext that can't access UnsafeNonFatal.

Why can't they access it?

Looks like testkit and std both depend on kernel and not core.

[durban]

Ah, of course... could we put this in kernel? It might be ugly, but it's private, so whatever...

Also, I don't really like the Unsafe prefix, but I don't really have a better idea, and it's probably good that it has a different name than the one in the stdlib, so... 🤷‍♂️

[CJSmith-0141]

Ah, of course... could we put this in kernel? It might be ugly, but it's private, so whatever...

Also, I don't really like the Unsafe prefix, but I don't really have a better idea, and it's probably good that it has a different name than the one in the stdlib, so... 🤷‍♂️

What about EffectRuntimeNonFatal ?

[armanbilge]

Looks like testkit and std both depend on kernel

testkit depends on core, but kernel-testkit does not.

Ah, of course... could we put this in kernel? It might be ugly, but it's private, so whatever...

Do we really need it in the other places? Fatal exceptions are a runtime concern, and all the fatal error handling machinery is in core, because that is where the runtime lives.

Meanwhile, if we pursue this thread we actually should consider moving it to Cats, which also uses NonFatal.

[kapunga]

Ah, of course... could we put this in kernel? It might be ugly, but it's private, so whatever...
Also, I don't really like the Unsafe prefix, but I don't really have a better idea, and it's probably good that it has a different name than the one in the stdlib, so... 🤷‍♂️

What about EffectRuntimeNonFatal ?

I started withRuntimeNonFatal so I could do that. I thought the name should be different so it's easily differentiable from regular NonFatal, but coming up with another name was hard...

[kapunga]

Do we really need it in the other places? Fatal exceptions are a runtime concern, and all the fatal error handling machinery is in core, because that is where the runtime lives.

Meanwhile, if we pursue this thread we actually should consider moving it to Cats, which also uses NonFatal.

I agree that it shouldn't be used elsewhere. In my experience, handling InterruptedException is usually only a concern if you are directly handling threads, so I don't think it should be caught anywhere outside of the fiber runtime.

[durban]

Yeah ok, fair enough. I'll stop nitpicking now... :-)

UnsafeNonFatal is also fine, I was just hoping someone'll have a better idea 🤷‍♂️