When the original method has a try...catch that contains function calls that are replaced by Async versions, the catch block potentially swallows the OperationCanceledException resulting in the task transitioning to the Faulted state instead of Cancelled

I propose that when a try...catch block exists in a method where the catch exception type is an ancestor of OperationCanceledException (SystemException, Exception), that another catch block is added for the OperationCanceledException that immediately re-throws.

e.g.
given the following method:

public void MethodThatCatchesExceptions() {	try	{	SimpleFile.Read();	}	catch (Exception ex)	{	throw new Exception("My wrapped exception", ex);	} } 

the transformed Async output is currently something like

public async Task MethodThatCatchesExceptionsAsync(CancellationToken cancellationToken) {	try	{	await (SimpleFile.ReadAsync(cancellationToken));	}	catch (Exception ex)	{	throw new Exception("My wrapped exception", ex);	} } 

whereas it should be

public async Task MethodThatCatchesExceptionsAsync(CancellationToken cancellationToken) {	try	{	await (SimpleFile.ReadAsync(cancellationToken));	} catch (OperationCanceledException) { throw; }	catch (Exception ex)	{	throw new Exception("My wrapped exception", ex);	} } 

I've got a failing test fixture I can provide, but I've had a brief look at the code and frankly have no idea where to begin to address the issue.

I tracked this issue from NHibernate which uses AsyncGenerator and is causing it to throw GenericADOException where it should throw an OperationCanceledException when cancelling queries such that the tasks return from the async query methods end up Faulted instead of Cancelled.