odersky

I think it's essential that both `Try` and `Future` also catch `Break` exceptions. Otherwise the following code would lead to a race condition when determining the result of `boundary`. ```scala...

Yes, if two futures both break they race for the value returned from boundary. The principal idea of a future is that all possible outcomes are accessed when the future's...

> If Future {} does not catch the Break, it will be sent for external reporting to the ExecutionContext, and the future itself will never complete. And this would be...

But a Future returns a Try. So sometimes the Try catches a Break and sometimes not? :confused:

> `Try { ... }` never catches Break. In what sense? I thought `Try` as it is now does catch `Break`, and I am arguing that's the correct thing.

I agree that `NonFatal` should be deprecated, but think we should recommend that people use `Exception` instead. As per JVM spec `Errors` should not be caught. > An Error is...

> I think that the point people want to make is that Break should have been an Error all along, according to that criteria, because the majority of use cases...

@adpi2 Some tests are still failing.

I wonder: Why did the original failing code get through the CI?

I see now it's already handled in #20355. On the other hand, maybe the fix here is preferable. I see that lots of classes have unimplemented `delete` methods. So maybe...