For try/catch statements and then/catch methods, the existing handling semantics are left as-is, but handling semantics are changed for HostPromiseRejectionTracker, such that instances of Cancel are not reported. It seems undesirable that (existing) global error handling would now have different semantics than (existing) local error handling.
I understand that it would be wrong to have HostPromiseRejectionTracker report cancels, so maybe the problem points the other way and catch should be updated to match.
I also understand the desire to leave the semantics of catch as-is, but I'm not sure that I understand the rationale completely. I hope we can agree that introducing a new "preferred" way to handle errors is extremely risky from a teachability perspective?
For
try/catchstatements andthen/catchmethods, the existing handling semantics are left as-is, but handling semantics are changed forHostPromiseRejectionTracker, such that instances ofCancelare not reported. It seems undesirable that (existing) global error handling would now have different semantics than (existing) local error handling.I understand that it would be wrong to have
HostPromiseRejectionTrackerreport cancels, so maybe the problem points the other way andcatchshould be updated to match.I also understand the desire to leave the semantics of
catchas-is, but I'm not sure that I understand the rationale completely. I hope we can agree that introducing a new "preferred" way to handle errors is extremely risky from a teachability perspective?