async 메서드의 void 반환 타입 사용에 대하여
예전에도 한번 소개했는데, async/await 관련해서 권장하는 글입니다. ^^
Async/Await - Best Practices in Asynchronous Programming
; https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/march/async-await-best-practices-in-asynchronous-programming
번역하신 분도 계시네요. ^^
[.NET] Async/Await - Best Practices in Asynchronous Programming #1 (번역)
; http://sweeper.egloos.com/3193944
[.NET] Async/Await - Best Practices in Asynchronous Programming #2 (번역)
; http://sweeper.egloos.com/3193943
그런데 "
Async/Await - Best Practices in Asynchronous Programming" 글에 대해 좀 더 보충 설명이 필요할 것 같아 이야기를 써 봅니다. ^^
해당 글의 "Figure 2 Exceptions from an Async Void Method Can’t Be Caught with Catch" 예제를 보면,
private async void AsyncVoid()
{
throw new InvalidOperationException();
}
public void CallAsyncVoid()
{
try
{
AsyncVoid();
}
catch (Exception e)
{
// 이곳의 코드는 절대 실행되지 않음.
Console.WriteLine(e.ToString());
throw;
}
}
위의 코드에 대해 async void로 했기 때문에 예외를 잡을 수 없다고 오해하실 수 있습니다. 물론, 위의 코드는 catch 문의 예외 핸들러가 절대로 실행되지 않습니다. 그 이유는, 위의 코드를 컴파일러가 어떻게 번역하는지 따져 보면 알 수 있습니다.
C# 컴파일러 대신 직접 구현하는 비동기(async/await) 코드
; https://www.sysnet.pe.kr/2/0/11351
컴파일러는 async가 붙은 메서드는 언제나 StateMachine을 구현한 클래스로 코드를 대체해 AsyncVoidMethodBuilder.Start 메서드에 태워 실행합니다. Start 메서드가 실행되어 처음 StateMachine.MoveNext 메서드가 실행될 때는 호출자 측의 스레드 위에서 실행됩니다. 게다가 StateMachine은 MoveNext에 옮긴 async void의 코드에 대해 try/catch 처리를 하기 때문에 위의 CallAsyncVoid 메서드 내에 있는 try/catch가 실행되지 않는 것입니다.
정리해 보면, 결국 위의 코드는 다음과 같은 식으로 번역되어 실행되는 것과 비슷한 효과를 갖습니다.
AsyncVoidMethodBuilder _builder_of_AsyncVoid;
private async void AsyncVoid()
{
try
{
throw new InvalidOperationException();
}
catch (Exception e)
{
_builder_of_AsyncVoid.SetException(e);
}
}
public void CallAsyncVoid()
{
try
{
AsyncVoid();
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
throw;
}
}
이 때문에 사실 AsyncVoid 메서드를 async void가 아닌 async Task로 정의해도 마찬가지로 catch 예외 핸들러는 실행되지 않습니다.
private async Task AsyncTask()
{
throw new InvalidOperationException();
}
public void CallAsyncTask()
{
try
{
AsyncTask();
}
catch (Exception e)
{
// 이곳의 코드는 절대 실행되지 않음.
Console.WriteLine(e.ToString());
throw;
}
}
왜냐하면, 이 호출 역시 async 예약어가 붙은 AsyncTask 메서드 내의 코드가 다음과 같은 식으로 변경되기 때문입니다. (단지, AsyncTask의 끝에 Task 객체를 반환하는 정도만 차이가 납니다.)
AsyncVoidMethodBuilder _builder_of_AsyncTask;
private async Task AsyncTask()
{
try
{
throw new InvalidOperationException();
}
catch (Exception e)
{
_builder_of_AsyncTask.SetException(e);
}
return _builder_of_AsyncTask.Task;
}
public void CallAsyncTask()
{
try
{
AsyncTask();
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
throw;
}
}
즉, async Task가 아닌 async void로 정의했다고 해서 예외가 실행되지 않는 것은 아닙니다. 대신 async void가 아닌 async Task로 정의했을 때는 await을 사용할 수 있기 때문에 코드를 다음과 같이 바꿔줄 수 있는 것입니다.
public async void CallAsyncTaskAwait()
{
try
{
await AsyncTask();
}
catch (Exception e)
{
// 이곳의 코드는 절대 실행되지 않음.
Console.WriteLine(e.ToString());
throw;
}
}
AsyncTask에 대해 await을 호출했기 때문에 당연히 그것을 호출하는 메서드에도 async 예약어가 붙게 됩니다. 이렇게 바뀐다고 해서 AsyncTask 메서드의 코드 번역이 바뀌는 것은 아닙니다. 즉, 여전히 AsyncTask 메서드에서는 다음과 같이 try/catch가 있어 예외 처리가 되어 있습니다.
AsyncVoidMethodBuilder _builder_of_AsyncTask;
private async Task AsyncTask()
{
try
{
throw new InvalidOperationException();
}
catch (Exception e)
{
_builder_of_AsyncTask.SetException(e);
}
return _builder_of_AsyncTask.Task;
}
하지만 AsyncTask를 await으로 호출하는 CallAsyncTaskAwait가 async 메서드로 바뀌었기 때문에 다음과 같은 식으로 코드가 바뀝니다.
TaskAwaiter _awaiter_of_AsyncTask;
int _step = 0;
public async void CallAsyncTaskAwait()
{
if (_step == 0)
{
// AsyncTask 메서드가 Task를 반환하므로 Task.GetAwatier 메서드를 호출하도록 변경할 수 있음.
_awaiter_of_AsyncTask = AsyncTask().GetAwaiter();
_step = 1;
_awaiter_of_AsyncTask.OnCompleted( () => CallAsyncTaskAwait() );
}
if (_step == 1)
{
try
{
// TaskAwatier의 GetResult는 AsyncTask() 메서드에서 AsyncVoidMethodBuilder.SetException으로 예외가 설정되었다면,
// 그 예외로 throw task.Exception; 을 수행함.
_awaiter_of_AsyncTask.GetResult();
}
catch (Exception e)
{
// 원래 CallAsyncTaskAwait에 있었던 catch 코드가 이곳에 있음.
Console.WriteLine(e.ToString());
throw;
}
}
}
즉, async가 적용된 AsyncTask의 내부에서 예외가 try/catch로 처리되었지만 그것이 AsyncVoidMethodBuilder.SetException으로 보관되어 있었으므로 이를 TaskAwatier.GetResult() 메서드 내에서 구해 throw 처리를 할 수 있었던 것입니다.
만약 AsyncTask 메서드가 Task를 반환하지 않는 async void였다면, 그것을 호출하는 CallAsyncTaskAwait 메서드에서는 Task 객체의 GetAwaiter()를 호출할 수 없어 결국 TaskAwatier.GetResult 메서드도 사용할 수 없어 예외가 먹히는 것입니다.
(참고로, 이 글의 async 코드 처리는 개념적으로 비슷하게 한 것일 뿐 실제로는 "
C# 컴파일러 대신 직접 구현하는 비동기(async/await) 코드)" 글과 같이 복잡하게 바뀝니다.)
(
첨부 파일은 이 글의 예제 코드를 포함합니다.)
자, 그럼 "
Async/Await - Best Practices in Asynchronous Programming" 글을 다시 정리해 보겠습니다.
해당 글에서는 다음의 3가지 가이드라인을 제시합니다.
- Event Handler를 제외하고 async void의 사용은 피한다.
- Console 프로젝트의 Main 메서드를 제외하고 호출 그래프의 상위를 모두 async로 바꾸며 blocking 코드를 넣지 않는다.
- Context가 필요하지 않다면 ConfigureAwait(false)를 호출한다.
첫 번째는 당연하니 넘어가고.
두 번째는 C# 7.1부터 Main 메서드에도 async Task를 적용할 수 있으므로 이제 "예외 없이 async로 바꾼다"로 변경해도 됩니다.
세 번째는
다음번에 다룰 텐데, 다른 말로 하면 UI 요소를 건드리지 않는다면 ConfigureAwait(false)를 항상 호출하는 것이 권장된다고 여기시면 됩니다.
이 글을 쓰면서 궁금한 사항이 하나 생겼습니다. async가 적용되면 마이크로소프트는 내부에 await 호출을 하지 않아도 해당 메서드를 상태 머신을 갖는 클래스로 바꿔 버립니다.
그런데, await 호출이 없는 메서드를 굳이 async 예약어가 적용되었다고 상태 머신을 갖는 코드로 바꿀 필요가 있을까요? 글쎄요, 제가 아는 한 없는 것 같습니다. 단지, 마이크로소프트가 일관성을 유지하기 위해 await이 없는 호출에도 async를 적용한 것이 아닌가... 예상해 볼 뿐입니다. ^^ 혹시 다른 의견 있으신 분은 덧글 부탁드립니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]